On Mon, 2006-01-30 at 21:36 +0100, Michael Wechner wrote:
> Josias Thoeny wrote:
> 
> >On Mon, 2006-01-30 at 17:13 +0100, Andreas Hartmann wrote:
> >  
> >
> >>Felix Röthenbacher schrieb:
> >>
> >>[...]
> >>
> >>    
> >>
> >>>>However, it is quite unclear to me how such a navigation framework would
> >>>>look like, so I don't know how to write the input modules either.
> >>>>        
> >>>>
> >>>Maybe we should discuss this topic first. Anybody any ideas?
> >>>      
> >>>
> >>We already discussed some ideas in the thread "Mapping URLS to
> >>documents", but IMO the important points get lost in the discussions.
> >>Maybe we can express our opinions using some basic axioms.
> >>I'll start trying to summarize my wishlist:
> >>
> >>- The navigation framework is responsible for expressing
> >>   - the mapping between URLs and pages [1]
> >>   - navigation aspects of dependency relations [2]
> >>   - providing a standardized interface to build navigation widgets on
> >>
> >>- Multiple navigations are allowed per site.
> >>    
> >>
> >
> >
> >Could anyone provide an example which shows the benefits of multiple
> >site structures per site?
> >  
> >
> 
> e.g. http://www.lavafilm.com/

This site seems to have a flat url space and a (probably) static menu.
The urls of the german pages are different from the english pages
(gallery.html vs. galerie.html)
But personally I don't think it adds much value to have multi-lingual
urls.
Or do you think it does?


> >To me this point seems to add quite a lot of complexity.
> >  
> >
> 
> why?

One problem I see is the parent-child relations.
For example, now it's not possible to publish a document if its parent
is not published. This guarantees some kind of "integrity".
If you have multiple hierarchical site structures, you cannot have this
kind of dependency constraints. Probably there would be a default
structure, and the constraints are imposed only on that structure. But
IMHO this is somewhat confusing.
And what if a user wants to perform operations like "publish subtree" on
an alternate (unconstrained) structure? 

And how would an additional site structure be created and edited?

When Lenya creates a link from a unique ID, how does it determine which
url space to use? From the current request, or from the session?

When you insert a link in BXE or another editor, which site structure
will be used to display the tree?

(I know some of these points are not important now, since we don't have
to implement them, it's just about making it possible in the API. I just
wanted to express that it's still a little unclear to me what a
navigation framework actually is.)

I still think that multiple site structures is FS (flexibility syndrome)
until someone shows me a usecase which clearly shows some benefits.

Josias



> 
> Thanks
> 
> Michi
> 
> >The other points make sense to me, thanks Andreas for writing this
> >summary.
> >
> >Josias
> >
> >  
> >
> >>- Within a single navigation, a specific view of a content item
> >>   can be mapped to a unique URL. [3]
> >>
> >>- Within a single navigation, a URL can be mapped to a specific view
> >>   of a specific content item.
> >>
> >>- The language information can be arbitrarily expressed in the URL. [4]
> >>
> >>- For different views, the URL suffix (.html, .pdf) is used.
> >>
> >>- It is possible to create at least one (default) navigation without
> >>   using a reserved URL prefix.
> >>
> >>- It's fine with me to require URL prefixes for additional navigations.
> >>   Other options would be the session or request parameters.
> >>
> >>
> >>That are my CHF 0.02 for the moment.
> >>
> >>-- Andreas
> >>
> >>--------
> >>
> >>[1] What an actual page looks like should be handled by other mechanisms
> >>like XInclude. In a first step, this point translates to "the mapping
> >>between URLs and content items".
> >>
> >>[2] E.g., parent-child relations in hierarchical structures. Other
> >>dependency relations like references should be handled by the content
> >>repository.
> >>
> >>[3] E.g., give me the URL of the PDF view of the content item
> >>"product (english)" in the navigation "customer".
> >>
> >>[4] E.g., /en/foo, /foo_en, /foo-USA, /foo-011, ...
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>    
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >  
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to