On 1/31/06, Josias Thoeny <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-01-30 at 18:27 -0500, [EMAIL PROTECTED] wrote:
> > On 1/30/06, Josias Thoeny <[EMAIL PROTECTED]> wrote:
> > > Could anyone provide an example which shows the benefits of multiple
> > > site structures per site?
> > > To me this point seems to add quite a lot of complexity.
> >
> > If multiple indexes are easily created, then you can have:
> > - standard hierarchical menu: all Documents under parents.
> > - alternate hierarchical menus (only certain DocTypes, or by Author
> > then last update)
> > - flat alphabetical by Title
> > - flat by DocType, with a secondary sort by Title or last update.
> > - flat by CreatedDate or LastModified (useful for the RSS Module)
> > - (for authoring) flat for "submitted but waiting for approval."
>
> These examples make perfect sense to me, but IIUC they could be handled
> as "navigation widgets" only and don't need to be reflected in the URL
> space.
> I mean, one could just write a generator which generates a list of all
> documents, sorted e.g. by title or filtered by doctype, and display this
> list as a navigation menu on the page, whereas one document would have
> the same URL in different navigations.
>
> Or did I misunderstand you?
Most of the examples are possible using XSL transformations on a
massive sitetree. Most of the examples are much easier to implement,
and much faster, if the platform supports multiple multiple indexes.
The indexes would also support things that would be difficult without
them, like security and flat views including documents without
published parents.
This is about document storage and retrieval of a "sitetree".
This is not about the URLs. They can be decided from the context.
Example: Alternate hierarchy index "myView"
<map:generate type="sitetree" publication="{1}" index="myView"/>
The document selection and sorting is handled by the index. Then a
"url" property could be added to each document entry based on the
current context, either by the Sitetree Generator, or by XSL using the
hierarchical relationship between the Document nodes (like the current
system).
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
