Re: MRFC: Midgard site startup and configuration.

Correct me if im wrong .. but i think that torben and bergie has talked
about moving the majority of m-t into midcom .. and make a minimal
version of m-t that only initialises the site ..

/Johan "SmallOne" Bernhardsson

On Tue, 2006-02-07 at 10:20 +0100, Piotras wrote:
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe-b5ZhpPVuLA+tlBvVaVFjCkB+6BGkLq7r@public.gmane.org
> For additional commands, e-mail: [email protected]
> 
> 
-- 
Johan Bernhardsson

Linux/CMS/Network Consultant

Phone:  +46-13-73244
Mobile: +46-705-111751
Fax:    +46-13-73190
Email:  [email protected]
Web:    www.anykey.se

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBD6Gd35oUA6E58WOMRApP8AJ49EqoHXSc70TTk6r1OOraiBlA2RwCfS7We
pfouDzKekjksMae2cQSvtqo=
=G0Ne
-----END PGP SIGNATURE-----