Adam Blomberg wrote:
> > 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.)
Right, which is why the 'fetch by name' approach has been added to 1.4
> > 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.
You'd still need to tell which page is the parent page of an article, so
in this case instead of hardcoding a topic number in the page code you'd
be hardcoding a page number in each article.
Besides, the separation between content and representation makes things
like http://www.midgard-project.org/ and
http://lite.midgard-project.org/
possible. When articles are tied to a representation page you can't do
that.
> > 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.
I think that lookup by path has been added to 1.4. If not, this may be
useful.
Looking at it from a purely personal point of view, the only essential
thing
is to have a way to look up the content root by name instead of
numerical ID.
I don't need to have the site hierarchy represnted in the URL as seen in
the
Location: field, so given that the root-lookup issue has been solved it
doesn't
matter to me that access to content that lives in
'Root topic'/'sub topic'/'sub sub topic'/'article name' is accessed by
http://www.site.com/party/72345.html
> > > 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 :)
The page records are formatting templates, only there's no hardcoded
relation between content and presentation. And page records can display
more than just articles or topics; the online manual on the
midgard-project
site displays generated files.
Emile
--
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]
