Re: MRFC: Midgard site startup and configuration.

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

Hi Tarjei,

- --Tarjei Huse wrote on 2006-02-07 14:48:
>> 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 ;-)
>
> In my experience, MIDCOM_ROOT must be an absolute path anyhow. I think 
> what I did with my testing was to let midcom.php set MIDCOM_ROOT based 
> on the __FILE__ constant.

Yeah, this autodetection works fine. I merely mentioned it for completness.

The Template should have some way, perhaps in an advanced tab, to actually set
the path to midcom.php. The case where you have two sites, one development, one
live, on the same server running different trees should be suppported by the
template using this feature.


>>> 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).
>
> Hmm, I'm not completely with you here.

Now that I read this sentence again, I don't wonder. ;-) Let me rephrase

> What you're saying is that the code-* elements should follow the style, right?

Basically yes.

What bothers me most in current m-t is that all sites share a root page. There
is no way of having separate root pages where you need it. (Which will be a
major problem with the page transition.)

Instead of using a common root page, we should introduce a "base MidCOM style"
which holds all template elements including some code-global, which will be
inherited from there -- if required for general template startup (I'm actually
not sure if we really need them).

We could even go as far as including ROOT and HEAD elements in there including
all standard stuff and creating a prepared BODY element with the call to the
body includes of MidCOM.

This way you have your own personal page without sacrificing the flexibility of
the templating system. The only single point where this needs some customizing
is the fact that each page throughout all MidCOM site must now call
$_MIDCOM->content() on their own.


>> 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.)
>
> Managed here means "The user edits it through a form" , right?

Yes.

I just usually use the broader term, as the UI the user sees is a) no single
form and b) might have derived values.


>> 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).
>
> Good tip. I guess what we should do then is to have one page per host and
> then the computed element as an element to that page? I do not want to create
> one style per host...

Good point as well yes.

The auto-generated elements must be in the root page's elements.

But nevertheless I think that the template should ship with a base style, from
which all sites inherit.

Actually we could ship with several styles: A simple one that just does the
absolute minimum to get the template going, and a more advanced mimicking the
current m-t with its dozen helper elements like <(breadcrumb)> and a pre-managed
HTML construct (as outlined above).


>> 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.
>
> Hmm, following your tips on caching above, I suggest they all become 
> page-elements. What I'm not sure about is if
> there should be sitegroupwide configuration options, and if so, if they 
> need to be in their own element or just included into the generated code.

SG-wide options would be an interesting idea, they could be linked to SG-config.

You could of course just call a corresponding style element (like
<(midcom-template-sitegroup-startup)> or <(midcom-template-sitegroup-config)>)
at the appropriate places in the startup. In case a user wants SG-wide defaults
etc., he can just use a common base style (derived from the template styles) for
all his sites and put these elements into it.

Btw. I am planning to build more flexibility in the SG-Config system. Mainly,
because in my next project I have to run two sites in the same SG with their own
"sitegroup-config" snippetdir. So there will be a "sitegroup_config_path" option
in MidCOM soon.

On a side note: Component configuration is another thing I want to upgrade a bit
when we go for PHP5, essentially starting to distinguish sitegroup- and
site-configurations.


>> 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.
>
> This could actually be the change we do in root. We could add 
> midcom-start and midcom-end elements that only exist in midcom sites.

Maybe, yes. That way we'd keep code-global etc. free for "traditional" usage.

What about a startup sequence like this

<(code-midcom-start)> <-- This element is autogenerated as outlined above
<(code-global)>
<(code-init)>
<(ROOT)>
<(code-finish)>
<(code-midcom-finish)> <-- Calling $_MIDCOM->finish();

I have prefixed the elements with code- to stay in line with the other elements.

Noteworthy: The autogenerated code-midcom-start will call $_MIDCOM->code_init();
so that MidCOM is up and running once code-init is called. Usually we won't need
code-global/init unless you do site-specific initializations in it (later
page-specific).

code-midcom-start could also start up the leight-weight MidCOM we envision to
support the old legacy API.


> The idea for the nulltopic is that this may be used in situations where 
> we want to start a component without a given topic.

As a temporary solution, that could be done yes. At least until we can start up
MidCOM without a topic after the request handling rewrite. From there we should
be able to work without such workarounds (in combination with code-midcom-start).


>> 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.
>
> Hmm, I will separate out that part to it's own mRFC, but it is usefull 
> to know about.

Yeah, we need to take it into account. I just wanted to point out the
distinction that should be made there.

Actually, I think most Site management should move on-site anyway, with the ACL
system this is actually rather easy. The only thing that is currently not easily
possible here is topic management (creation/etc.) where I still have to relay to
 AIS.

What I'm thinking here is providing a DL, which is automatically included by the
base classes into the request switch. It'd add the topic management funciton to
each and every topic handler implicitly. That would deprecate the whole idea of
a separate AIS if done right. ;-)


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

iD8DBQFD6bDnJPh4Kn6d5FYRAghwAJ9HZSv0FnY46ly0lgoPlDqIZ82/CACeMFg0
+qnGqz372KSyxK1OhQLS7SE=
=D3r1
-----END PGP SIGNATURE-----