Re: MRFC: Midgard site startup and configuration.

Tarjei Huse <tarjei-y/[email protected]> wrote:

Hi, 
( do not kill me ;)

> MRFC: Midgard site startup and configuration.
> 
> This is an outline for how future MidCOM Sites should be created and
> configured.
> 
> Background: 
> The current solution to set up MidCOM sites uses the Midgard Template to
> create sites. The current template is slow and is hard to modify and
> work with. 

I am not any component developer but:
Two sites I initilized without M-T are not working anymore and frankly speaking 
I have no time or will to debug what happened. 
However M-T is slow I vote for M-T. Reason is very simple. I know that M-T based
sites are going to work as expected. 
 
> Site configuration
> Today site configuration is contained in parameters to the host. This is
> fairly inefficient as this generates a large set of queries to the
> database on every request. 
> 
> Instead of keeping the configuration in parameters it should be kept in
> a simple snippet that may be included into the request.
> 
> This snippet should be named:
> /sitegroup-config/hosts/<id-of-host> 

Today we have MgdSchema and we can create midcom optimized objects to 
configure such things.
 
> The following parameter must be set in the configuration:
> 
> $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] =
> "860f1b5af98b409abd916a80cdb0d68e";

$some_midcom_object->root is much more readable than arrays' hell.
 
> The $GLOBALS['midcom_site'] array
> Today, the template populates the midcom_site array with some objects as
> well. It is my suggestion that this array is created when editing the
> host settings but that the objects are left out. Another option is to
> link the objects to objects within the MidCOM framework.

As above :

$some_midcom_site->port
$some_midcom_site->prefix 
$some_midcom_site->whatever 

Is *much* more readable than another set of huge set of arrays.

> Placing the MidCOM elements in midgard-root.php. 
> It is an option to place the MidCOM elements in midgard-root.php. As
> long as there is a simple way to handle non-MidCOM applications I
> strongly suggest this is done.

What is needed is some element reserved for site developer which can be 
called before code-global is executed.
 
> One way to do that is to make a mock MidCOM object that is used when the
> site is a non MidCOM site. This would make the content in the
> style/midgard-root.php cleaner. Another option is to branch
> midgard-root.php for separate handling of MidCOM requests.

If this is doable ( reasonable ) , it can be done after 1.8.
It's related to style engine rewrite. 
Much more efficient and easier is writing contorl structures for <(elements)>
instead managing those in root file ( whataver it looks like ).
Briefly it comes down to the same thing.

> What are the best ways to mark/detect a MidCOM request from a non-midcom
> request? Is it needed?

Move some part of code to the place which is perfect for php frameworks - php extension.
 
Piotras