On Mon, 11 Sep 2000, Emiliano wrote: > Adam Blomberg wrote: > > My problem is this: The major parts of the site will be administrated > > by a group of administrators, but then several departments will > > administrate their own pages (or subsites). For them (and for us), > > the content management part would be great, if you conveniently could > > map topics to pages, so that you can browse the topic structure > > without having to make an active page which handles all > > requests. (Btw, in the current stable version, this doesn't seem > > to be possible.) > > That would be how we usually handle it. It's possible with the current > stable version although you'd have to write the 'by name' access > functions > in PHP. These have been added as native midgard functions in the 1.4 > releases. > > You can attach data to pages in the 1.4 releases (attachments, > parameters) > although these will still need help from active pages to get served out. > > In what way does the active page approach not service your needs? Well, it would work, but I believe that this is a rather common situation (where some kind of mapping topics<->articles is used), so built-in support support for it might be good. (And probably faster than the PHP approach.) > > I would like it to work something like this: When you create a new > > topic (named "support" for example), a "virtual" page is also set up, > > based on a template (or parent) page of the current topic tree. All > > articles added to this topic would then be accesible by very > > simple means; as we know which topic we are in right know, one can > > simply fetch all articles which have the current topic as parent. > > But you'd need to have a standardized approach to formatting these > articles. I can't concieve of having a fixed formatting engine in > midgard. I thought of having a "parent" page, that contains all PHP code/HTML code/other formatting needed to present the material. In essence, this would be similar to an active page, but without having to do the lookup for the article to show. > > Another approach could be that each page created in the "page > > admin" results in a topic, that can then be filled with articles (and > > possibly other topics as well, depending on the user privileges). > > The page would then "know" which topic id that corresponds to the > > current page, so that you won't have to hard-code topics to pages > > (this is what I'm doing right know, slightly annoying :) > > I understand this problem. Access-by-name plus an active page has > been the approach I've taken so far. As I mentioned above, I think that this is a central function of any content management system, and the fact that you (and others) have used the dynamic page approach may imply that a native function for would be useful. > > Are there any functions that would support this proposed behavior in > > the upcoming versions, and if not, is there a better way to solve the > > problem of connecting content "folders" to actual pages? > > If there are, I'm interested. The main problem would be how to do the > transformation from raw content to HTML sent to the browser. If you could use a pages as formatting templates rather than as "site handlers, I think you have solved that problem :) // Adam -- This is The Midgard Project's mailing list. For more information, please visit the project's web site at http://www.midgard-project.org To unsubscribe the list, send an empty email message to address [EMAIL PROTECTED]
