Re: MRFC: Midgard site startup and configuration.

Torben Nehmer wrote:
> -----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 :-)
Thanks :-)

<(snip)> <- I'll include it in the mRFC somehow.


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


>> 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. What you're saying is that the 
code-* elements should
follow the style, right?

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

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

> 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.
> Of course, this means that one must no longer change the code of this
> auto-generated snippet manually.
That is the idea.

>> 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.
Ok, this sounds ok by me.

> 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).
+1 I've been thinking the same ideas.

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

> 
>> 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.
+1 on shipping some standard tools in SG0.

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

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


> 
> 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-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe-b5ZhpPVuLA+tlBvVaVFjCkB+6BGkLq7r@public.gmane.org
> For additional commands, e-mail: [email protected]
>