Preparing for alpha2 of Midgard2
-
Piotr Pokora
Preparing for alpha2 of Midgard2
Mon April 14 2008 11:00:03 UTCHi!
As you probably know ( or not ) I managed to run Midcom 3 on top of
Midgard 2 *without* apache module.
Pros and cons has been noted in another thread and things look very
promising.
In Midgard2 we have special midgard_request class and its object which
handles all mandatory request related informations, like style, pages,
argv and argc. This object is available as property of
midgard_connection singleton object ( $_MIDGARD_CONNECTION ).
I wonder about two issues:
* should it be singleton too?
If yes, I can instatiate it in request initialization for web
environment and
let application designer instatiate it in cli. I do not care if not :)
* Should we keep style, pages argv and argc properties keep read only or
constructor only?
* What should be the best place to keep its reference in Midgard 1.9, if
port could be done successfully?
Alpha2 should be released in April if there are no nasty surprises.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: [midgard-dev] Preparing for alpha2 of Midgard2
Mon April 14 2008 18:00:03 UTC-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Piotr Pokora wrote:
> Hi!
>
> As you probably know ( or not ) I managed to run Midcom 3 on top of
> Midgard 2 *without* apache module.
> Pros and cons has been noted in another thread and things look very
> promising.
>
> In Midgard2 we have special midgard_request class and its object which
> handles all mandatory request related informations, like style, pages,
> argv and argc. This object is available as property of
> midgard_connection singleton object ( $_MIDGARD_CONNECTION ).
>
> I wonder about two issues:
>
> * should it be singleton too?
I think not. How does the api for the object look?
The best way would be if this would be an object something like this:
$req = new midgard_request($argv, $argc);
$req->get_page();
then in a midcom dynamic_load() call:
$req = new midgard_request(array('test', 'calendar', 2);
$req->get_page();
Thus we would be a lot closer to implementing the dream of a paged midcom :)
regards,
Tarjei
>
> If yes, I can instatiate it in request initialization for web
> environment and
> let application designer instatiate it in cli. I do not care if not :)
>
> * Should we keep style, pages argv and argc properties keep read only or
> constructor only?
>
> * What should be the best place to keep its reference in Midgard 1.9, if
> port could be done successfully?
>
>
> Alpha2 should be released in April if there are no nasty surprises.
>
> Piotras
> _______________________________________________
> dev mailing list
> dev@lists.midgard-project.org
> http://lists.midgard-project.org/mailman/listinfo/dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIA5ofYVRKCnSvzfIRAmgWAJ9FJUXjUc3G8KZsFEoUw7BbzPBwVwCgkQta
IsjENeamlGYBeCMyOiu2yoM=
=o+nE
-----END PGP SIGNATURE-----
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Piotr Pokora
Re: [midgard-dev] Preparing for alpha2 of Midgard2
Mon April 14 2008 18:50:08 UTCtarjei writes:
>> * should it be singleton too?
> I think not.
I ask this question because I am not sure if we have any use cases to
change request's data
during request. Besides application should not create cases when
request data is changed.
By request, I mean web site request or cli process.
Basically, do we need read only data by convention or "technically" read
only?
> How does the api for the object look?
> The best way would be if this would be an object something like this:
>
> $req = new midgard_request($argv, $argc);
> $req->get_page();
Point is that we need to create argv and argc as the last part of url
translation.
So midgard_request should be initialized with *full* url which includes
host's name and port.
> then in a midcom dynamic_load() call:
>
> $req = new midgard_request(array('test', 'calendar', 2);
> $req->get_page();
Ah, midgard_request is not about creating requests. It should hold
global informations about
current request. Should we probably change class name?
Currently request object holds these properties:
* host, midgard_host object
* page, midgard_page object
* pages, array of midgard_page objects
* style, midgard_style object
* uri, $_SERVER[REQUEST_URI] /* which should be redefined with prefix
excluded */
* argv, array
* argc, int
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: [midgard-dev] Preparing for alpha2 of Midgard2
Tue April 15 2008 05:15:03 UTCHi,
On Mon, Apr 14, 2008 at 8:53 PM, tarjei <tarjei@nu.no> wrote:
> then in a midcom dynamic_load() call:
>
> $req = new midgard_request(array('test', 'calendar', 2);
> $req->get_page();
>
> Thus we would be a lot closer to implementing the dream of a paged midcom :)
This would be helpful, but page-based dynamic_load already exists
using the APIs we have in MidCOM 3
http://www.midgard-project.org/api-docs/midcom/3.0/midcom_core/midcom_core_services_templating_midgard.html#dynamic_call
> Tarjei
/Henri
--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/
Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
Re: [midgard-dev] Preparing for alpha2 of Midgard2
Sun April 20 2008 20:09:07 UTCHi!
Ah, midgard_request is not about creating requests. > It should hold global informations about current request. Should we probably change class name?
I'll change class name to midgard_request_config.
Piotras
-
Re: [midgard-dev] Preparing for alpha2 of Midgard2
Fri April 25 2008 04:37:59 UTCHi,
I'll change class name to midgard_request_config.
Ok, this seems good. The dispatcher MidCOM3 uses in Midgard2 environments utilizes this now:
http://github.com/bergie/midcom/tree/master/midcom_core/services/dispatcher/midgard2.php
So far things seem pretty good in Midgard2 land.
For alpha2, the main issues I see:
- midgard_user::auth causes a segfault on PHP
- for some reason collector returns GUID values of parameters as empty arrays
- midgard-python still doesn't compile on OS X
In addition to these, it would be super-cool, if alpha2 had:
- RPMs and DEBs built on the openSUSE build service
- mono bindings as part of the deal if Everaldo gets them working
After this we can start targeting at more user-friendly alpha3, with:
- MidCOM3 from PEAR packages
- Some kind of data installer to set up initial website with MidCOM3
/Bergie
