On 1/31/06, Josias Thoeny <[EMAIL PROTECTED]> wrote: > 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: > > >>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. > > >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?
An editor using the hierarchical view would enforce the integrity rules. It could also easily handle "Publish Subtree". An editor using the flat view could publish Documents that are the children of an unpublished Document. Those Documents would show in the flat views, but would not appear in the hierarchical views until the parent is published. The flat view should support publishing multiple documents (using checkboxes), but the integrity rules are bypassed. One of the important flat views would be "Unpublished Documents" so people can see what is missing. > And how would an additional site structure be created and edited? Probably a "Create new hierarchy" that names the new grouping and allows the Documents to be moved without affecting the primary parent-child relationships. If the platform supports it, people will develop methods of using it eventually. > 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? My recommendation is to support both. Every document has two URLs: /pub/docunid (hopefully never seen by visitors) /pub/primaryparentpath/docid With multiple parents, alternates are allowed: /pub/alternateparentpath/docid The Document.getURL(contextURL) function allows finding the closes valid URL for this document based on the current context. > When you insert a link in BXE or another editor, which site structure > will be used to display the tree? The tree used for selection is up to the editor module. I would like Lenya-specific links to be XML links rather than specific URLs: <link unid="xxx">text</link> When the Document is retrieved, these are replaced using Document.getClosestURL(): <a href=/pub/path/docid.ext>text</a> With this, a document can be moved or accessed from different trees, but the links are automatically updated, and the URL displayed will be sensible. > (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 I think the core platform should be extremely flexible as long as it extends the usefulness as a CMS. The functionality being discussed belongs in the core. It is easier to design for this functionality now rather than later. It should not add much complexity if implemented now; most of the code only needs a few lines to handle the addtional functionality. And the additional flexibility will be very powerful as developers start using it. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
