Re: MRFC: Midgard site startup and configuration.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

- --Tarjei Huse wrote on 2006-02-06 17:57:
> Hi, out of frustration  with the current M-T I have written a draft mRFC
> for how Midcom Templates should be handled in the future. Please read
> through it and comment it. I haven't added it to the mRFC's list yet as
> I want to see if the ideas presented are usefull in this form.

First of all good work :-)


A few remarks:


> The most basic site template for use in MidCOM is this:
> <?php 
> $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] =
> "860f1b5af98b409abd916a80cdb0d68e";
> require 'midcom.php';
> $_MIDCOM->codeinit();
> ?>
> [...]

Fully correct.

On a personal note, I usually use startup code like this one, for better
readability (see below for notes):

 // ============ CONFIG START
 $config = Array();
 $config['midcom_ais_url'] = '/admin/';
 $config['midcom_root_topic_guid'] = "23250188e139c46de166a686088c3415";

 // Advanced logging
 if ($_SERVER["REMOTE_ADDR"] == "217.186.90.163")
 {
     $config['log_filename'] = '/var/log/midgard/midcom/filmportal-torben.log';
     $config['log_level'] = 4;
 }
 else
 {
     $config['log_filename'] = '/var/log/midgard/midcom/filmportal.log';
     $config['log_level'] = 1;
 }

 $GLOBALS['midcom_config_local'] = $config;
 // =========== CONFIG END

 // Start up MidCOM
 define('MIDCOM_ROOT', '/home/torben/midcom-dev/lib');
 require(MIDCOM_ROOT . '/midcom.php');

 // =========== CUSTOMIZED STARTUP START
 // Force languages
 $_MIDCOM->i18n->set_language('de');
 $_MIDCOM->i18n->set_charset('UTF-8');

 // We run completly uncached for now (regarding content)
 $_MIDCOM->cache->content->no_cache();
 // =========== CUSTOMIZED STARTUP END

 // Execute
 $_MIDCOM->codeinit();

This snippet is taken from a semi-production site and shows a few more advanced
options in it. Noteworthy is the logging-switch that allows full logging in a
separate site for a single IP only, keeping the regular operation in another
log. Very useful to debug production sites. (With 3.0 request handling I might
incorporate something like this into the session scope of MidCOM, but so far,
this is the only viable solution.)

The configuration is made using a $config shortcut, just because I'm a lazy
typer, of course it isn't strictly neccessary.

The startup part I use is probably deprecated, with PEAR stuff we don't need
that way anymore. But nevertheless it is useful to statically set at least
MIDCOM_ROOT if you want the last, tiny bit of performance out of the site ;-)

Then we have the "customized startup" part, which sets languages / charsets
etc., which is sometimes neccessary to force a site into a given language.

Just for a more advanced how-to how I currently set up sites.


> 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> 

I originally had a bit of a different thought, basically having a
site-management component which creates a static code-global snippet for the host.

In my eyes the new template should only provide convenience elements, the
*standard* startup page elemenets (code-global and/or -init) should stay on the
target site (thus created in the style).

That code-global startup-element would have auto-created and custom parts, but
will always be managed through a component (unless, of course you really really
know what you're doing.)

I would avoid using snippets in the live code since (I have just asked Piotras
about this) they aren't covered by the preparser cache. Instead create a number
of snippets, managed by the site management system, which are pre-computed into
the style/page elements (which are covered by the preparser).

As I said, the configuration will have both managed parts and places where
custom startup/configuration code can be added verbatim. A full code-init could
therefore look like this:

 [automated configuration code]
 [custom configuration code]
 require('midcom.php');
 [automated startup code]
 [custom startup code]
 $_MIDCOM->code_init();

The automated parts will use custom storage systems (perhaps still host params),
 while the custom parts will just be a pair of snippets (or still parameters,
since they're longtext). Ultimately, with a good site manager, storage location
becomes irrelevant.

Of course, this means that one must no longer change the code of this
auto-generated snippet manually.

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

That depends. For legacy compatibility, we should keep the difference. This
means especially (this is a bit a different of a stance then I had previously):

a) The root page stays as is.

b) The actual distinction between MidCOM and non-MidCOM sites is done by
   the site management system.

thus c), the full startup is in the custom-generated code and 100%
   site-specific.

Actually, I think that something like this should be the way to go:

The new Template does *not* use a common root page, like M-T does nowadays.
Reason: When we do the page transition, this is no longer viable (period).

Instead, I would use the style system to make the distinction, basing MidCOM
sites of a common base style. This'll give you the same "look and feel" from
current sites but will leave you much more customizability. The only change from
todays procedures is that code-global (or some other, yet-to-be-added element)
will be included from the style, not the page code. Actually I think it isn't
even that much off-track given the way we'll use pages (again) in the future.


> Site Configuration 
> 
> [...]
>
> The wizard should be runnable through midcom-exec using a
> dummy-topic[1]. This could be used in situations where one does not know
> what the site will be used for (f.x. because the customer hasn't said
> so).
> 
> [1] Dummy topic
> Midcom currently needs a topic to be able to run. By creating a set of
> dummy topics and then setting the
> $GLOBALS['midcom_config_local']['midcom_root_topic_guid'] it should be
> possible to run a normal midcom component without having to create a
> local topic for it. 

I would not do this.

Instead I would ship MidCOM with a full (MidCOM driven) Administration system
located in SG0. A2 perhaps. It must have the site management tool readily
available, and its login must be both able to work sg0'ed and sitegrouped. That
way we don't need any special administrative "tools" on the live site, available
to whatever tool we deem, but have a standard System Adminstration System again.

Note, that I wrote "System Administration" not "Site Administration". This tool
is targeted at administrators only. Site management (which includes styles, DM2
schemas etc.) isn't a topic here for me right now.


Live long and Prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:[email protected]
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6HVgJPh4Kn6d5FYRAk21AKDLnuMwZ56xqEx7EiH4Q8yCzsihSwCdGV+d
wDc2XnD8YgXbq/5OcLGe12A=
=J92D
-----END PGP SIGNATURE-----