-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Torben Nehmer wrote: | Hi,
Greetings!
| See my last mail about this subject, I'm missing a few things like site | configuration stuff in there.
Some chat here:
[11:12] Bergie: regarding configuration, I've added the midcom-template config as a new step in the mRFC [11:13] Bergie: however, so far MidCOM itself is *not* configurable, only components are... so I've left that out [11:13] torben: midcom itself is configurable [11:13] Bergie: how so? [11:13] torben: already we have a dozen of configuration options [11:13] torben: caching [11:13] torben: logging [11:13] torben: etc. [11:13] Bergie: those are already in midcom-template config [11:14] torben: i do not object, but I would very much like a config system i have outlined in my mails [11:14] torben: not only in m-t [11:14] torben: m-t is good for site local settings [11:14] torben: but not for general stuff [11:15] torben: imho stuff like temp directory for midcom (currently /tmp is hardcoded, not good) or the dbm handler should be configurable on a per-system basis /etc/midgard/midcom.conf [11:16] torben: also i would recommend moving the site specific data out from an array into an full-scale object [11:16] torben: this makes extension and modification at a later point far easier [11:16] torben: so that you have $GLOBALS['site']->feature_title etc. ... [11:16] Bergie: that is not the deal of the site wizard, though, although it will give a perfect excuse to change things in midcom-template too ... [11:24] torben: not of the wizard itself, no, but this whole thing should go a step further IMHO [11:24] torben: maybe under the title "Midgard/MidCOM Site management system" [11:25] torben: some pluggable mechanism that supports the various "targets" like midcom, openpsa or townporta [11:25] torben: +l [11:25] Bergie: thinks it should be the *next* version of the wizard... there is so much overlap between the initial config of the site, and changing the config later [11:26] torben: yeah, sure, but you should make a complete spec, not that we discover in 8 weeks that the site creation wizard is nice, but we have to rebuild 1/2 of it so that it works with the rest tooo [11:26] torben: -o [11:26] Bergie: to make this easier, I'm going to make the different parts of the wizard directly adressable by URL, so if you know your SG and host GUID you can make a link to "set up site" (config), etc [11:27] Bergie: but anyway, the plan for this first version is *only* assisting the creation of MidCOM sites [11:27] torben: what is far more important form me as a developer are two questions [11:27] torben: 1st how do i influence the site creation from a developers point of view [11:27] torben: 2nd how do we organize the configuration of the actual sites in a clean manner [11:27] Bergie: torben: pls read the latest version of the mRFC [11:28] torben: ok [11:28] torben: *reading* [11:28] Bergie: the "template site" (in this case, midcom-template) provides two interfaces: data initialization code and config schema [11:28] torben: "If port hasn't been filled 80 will be used." <-- use port 0 ? [11:29] Bergie: maybe [11:29] Bergie: yeah, why not... let the Apache config decide which port to use [11:29] Bergie: or ports, even [11:29] Bergie: that way single host can appear on 80 for browsing and 443 for editing [11:30] torben: i'm still not sure if local config should be stored at the host record, instead of the page [11:30] torben: the page is the actual "root" instance of midcom, not the host [11:30] torben: the same page can be used in more then one host actually [11:30] torben: and each should work with the same config i think [11:30] Bergie: yeah... but the point is that the page indeed is used by several hosts [11:30] Bergie: for example, www.nemein.com, www.ftc.fi and www.dialogi.fi all use same root page [11:30] torben: ahhhhh [11:31] torben: ok [11:31] Bergie: ...and they're different SGs and all [11:31] torben: all hosts use the same midcom-template page, right? [11:31] Bergie: yes [11:31] torben: ok [11:31] torben: i'm getting into this slowly [11:31] Bergie: OpenPSA does things differently, there the config information is stored in the SG object [11:31] torben: ok, clear [11:32] Bergie: ...but obviously that wouldn't work with m-t either [11:32] torben: regarding the "site structure definition format", i still propose not using arrays but classes there [11:32] Bergie: ...as you may want to have multiple sites in same SG with different config [11:32] torben: yeah [11:32] Bergie: torben: the "site structure definition" is still very much TODO. If you can make a solid proposal, please do [11:32] torben: not ad hoc ... [11:33] torben: it is a rather general comment at the moment [11:33] torben: beacuse of this: ... [11:33] torben: at the moment i'm batteling with arrays in several places of midcom (nap component interface, nap site interface, schemas ...), and extending them has already lead into dozens and dozens of if array_key_exists stuff cluttering up the code [11:34] torben: if i had used some class tree for this, it would be far easier to extend and manage [11:34] torben: i don't want you to go into the same trap ;-) [11:34] Bergie: optimally the site structure definitions could go as far as making some default configs for the components being used [11:35] torben: anyhow, you have a +1 for me for the general site creation wizard mrfc idea, if the implementation is extensible easily ;-) [11:35] Bergie: for example, if I select that I want to create a "blog" site, it should set up blog entry commenting via n.n.discussion automatically [11:35] torben: bergie: yeah, they could [11:35] torben: bergie: so even more you'll need a class hierarchy here [11:35] torben: bergie: the wizard will be a midcom, if i remember right? [11:36] Bergie: there should also be some linkage between the style templates and the site structure... if your selected style has a substyle matching the "class name" of some site structure part, that should be used for that topic [11:36] Bergie: yes, it will be a midcom [11:36] Bergie: so far I'm thinking midcom.admin.sitewizard [11:36] Bergie: doesn't want to have it appear in the component selector on normal sites [11:37] torben: please use org.midgardproject.sitewizard instead [11:37] torben: the midcom.* tree is reserved for midcom core stuff [11:37] torben: i'd rather patch another filter into create_topic.php [11:37] Bergie: and this wouldn't be core? the way to create midcom sites? [11:38] torben: the sitewizard intends to be generic, if i understand this right, creating other apps as well on the long run [11:38] Bergie: yeah, but MidCOM is Midgard Core now, so that is the main target [11:38] Bergie: on slightly longer run I also want to replace the clumsy init/config tools in OpenPSA and TownPortal as well [11:39] torben: is thinking [11:39] Bergie: but the point is, the site wizard won't have a single line of TP or OpenPSA -specific code, it will all be supported through the APIs [11:39] torben: i understand that [11:39] torben: what about creating a midgard. toplevel directory [11:39] torben: ? [11:40] Bergie: maybe. what would be the benefit in that? [11:40] torben: i want the midgard and pure-midcom stuff separated actually [11:41] torben: as i said [11:41] torben: midcom.* is for the Mid*COM* core, not the Mid*gard* one [11:41] Bergie: hmm... I don't really agree with you in this, but whatever [11:42] torben: well, then put it into midcom.admin [11:42] torben: or at least midcom.midgard.sitewizard? [11:42] torben: that should suffice as well [11:42] torben: midcom.admin is AIS stuff [11:42] Bergie: sure [11:43] Bergie: whatever you want... although I fail to see why this is not "a midcom admin utility" ... [12:03] Bergie: torben: see previous comments [12:04] torben: it is an admin utitilty written with midcom for midgard in general (on the long run at least) [12:05] torben: so essentially it should be midgard.admin.sitewizard from a namespacing point of view [12:05] Bergie: well, we can do that [12:05] Bergie: will it work if I create it under such dir? [12:06] torben: why shouldn't it work? [12:06] torben: namespacing are pure organization stuff [12:07] Bergie: ok, just wanted to check [12:09] torben: i'll add midcom.* to the filter list in the topic creation windodw [12:10] torben: er [12:10] torben: midgard.* that is
| Torben Nehmer
/Bergie
- -- Henri Bergius [EMAIL PROTECTED] Consultant Partner Tel: +358-20-198 6032 Nemein Oy http://www.nemein.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB5kpeNkT8k497k9IRAh9hAJsFgYTI2xKw0wMJ1VbKhdzbEca1vwCgjcz9 xsVuGGxbs3R6VnjuR8Gz4vw= =jNNv -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
