Open Source Content Management System

Preparing for alpha2 of Midgard2

  1. Piotr Pokora

    Preparing for alpha2 of Midgard2

    Mon April 14 2008 11:00:03 UTC
    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?

    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
    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
  2. 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
    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
  3. Piotr Pokora

    Re: [midgard-dev] Preparing for alpha2 of Midgard2

    Mon April 14 2008 18:50:08 UTC
    tarjei 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
    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
  4. Re: [midgard-dev] Preparing for alpha2 of Midgard2

    Tue April 15 2008 05:15:03 UTC
    Hi,

    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
    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
  5. Re: [midgard-dev] Preparing for alpha2 of Midgard2

    Sun April 20 2008 20:09:07 UTC

    Hi!

    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

    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
  6. Re: [midgard-dev] Preparing for alpha2 of Midgard2

    Fri April 25 2008 04:37:59 UTC

    Hi,

    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

    •  Reply
    • stock-icons/16x16/stock_help-agent.png Report abuse
Designed by Nemein, hosted by Anykey