On 1/10/06, J. Wolfgang Kaltz <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > === Text from other discussion > > The hierarchical index must exist, but does not need to be reflected > I am unsure whether such an index must / should exist. It certainly is > the case in the default publication, but would it be true in general ? > My feeling is: > it should be the responsibility of the site API to provide information > such as: > - what document(s) should I present to the user as a start page (the > bootstrapping) > - given a document X, what should be presented as "child" documents of > document X ? (in certain publications, this response may vary depending > on context, such as user type) > > In the default publication, this information is provided by reading the > sitetree.xml (or the corresponding JCR representation of the site tree).
The index replaces sitetree.xml when using flat storage. It is the "JCR representation of the site tree". One of the first things we need moving to a flat structure is an alternative to sitetree.xml. An exact replica of sitetree.xml can be built from the index and the documents. One of the advantages are that other indexes can be built and used. A "Discussion" document could show the content of all the children "BlogEntry" documents on the page, but still show the children "Discussion" documents in the menus. The "live" module for that publication might use 2 indexes: one for menus and one for the blog entries, or it could be implemented with one and some XSL. Another difference/advantage is the homepage can configured for the Publication. It does not need the reserved ID "index", although most Publications would start with that. A quick configuration change could use the document "homepage" or "homepageSummer" as the homepage. > Other publications could implement this API entirely differently, for > example without relying on a fixed tree. For example, I have a use case > as follows: the user clicks on a document in the navigation menu; it is > only at this stage that I can (dynamically) determine what the child > documents to be presented in the current situation are. I do not understand your example, but I think this is why the new flexibilty is important. > What does exist in this situation, as in the default publication > situation, is a tree of all nodes the user has opened (and can thus be > rendered as a navigation menu) So you are adding a history menu of all the documents the visitor has opened since some mark? I think most browsers include that functionality. > > An alternative would allow a document to have several parents: > > getPrimaryParent(UNID) > > getAllParents(UNID) > > getAllChildren(UNID) > > getAllPrimaryChildren(UNID) > > First, yes IMO a document should be allowed to have several parents > (document reuse). This is especially important if we allow a document to > consist of several document pieces (which I hope we can achieve in the > next generation). So you like the proposal. Document reuse is its primary purpose. > But actually, I wonder at which point we have to know what a document's > parents are ? Isn't it sufficient to know, for a given document, what > it's children are ? Maybe you are referring to access rights, such as: > if a document has no specific access rights, use its parent's access > rights to decide whether the user may see it. Do I understand correctly ? > This access right mechanism would be publication dependent. In the > current default publication, the parent is known from the URL. Other > publications, potentially using other navigation mechanisms, would have > to implement access decisions based on their specific navigation mechanism. > > > The multiple-parent index would look like: > > /foo > > /foo/aaa > > /other1 > > /other1/aaa > > /parent2 > > /parent2/other2 > > /parent2/other2/aaa > > > > This allows a document to appear at several places in the hierarchy. > > Sounds fine to me - > whereas, what I'm trying to say is: I don't think we need to change the > default publication right now to allow it to support multiple parents. I > do however think we should not implement anything in the core / JCR > storage / etc. which would disable the usage of multiple parents as > such. And we should try to make the Lenya 1.4 core API flexible enough > so as to not make any assumptions regarding a fixed, predetermined 1-n > parent-child structuring. Not forcing the 1:1 child:parent structure almost requires adding the 1:n child:parent structure to test we are supporting it. If the structure supports it, using it should require little extra code. If it does not support it, we will not know until we test it. At that point, why not add it to the default publication? > > If we want to allow multiple parents, this functionality should be > > designed into the core as early as possible. Adding it later could > > require rewriting many basic functions. Specifically it means the > > addition of a Document property to store the multiple parents, and > > support for multiple indexes. > Well, I'm not sure that this is what it means :) Again, we have to > distinguish what is publication dependant, and what is general (core). > Unfortunately I admit that I currently lack the knowledge to say "we > must change exactly this and that in the core API to achieve this goal". I have not read the core code in the context of adding functionality. But given Lenya's purpose, and the move to flat storage, my suggestions are standard functions. I need to read the new "repo" code soon to start working on these suggestions. > This touches upon the discussions regarding scope of Lenya in the past > days. I actually agree with everyone ;) The default publication can be > used as a CMS for "common" Web sites (such as ours, used for > straightforward information delivery, of well-known and structured > information). But the particular added-value of Lenya should be the fact > that it can be used as a CMS framework, that's why it's important to > keep non-default-publication needs in mind, even if they appear strange > or uncommon :) Let us not discuss "framework" vs. "usable application" again here; the different perspectives do not matter to this discussion. Every one of my suggestion is about improving the flexibility of the framework. Almost every suggestion implemented in the framework should be available in the default publication for several reasons: - Test the functionality works, and continues to work after other development. - Showcase the functionality, so it is on the feature list, and as example code. - Allow newbies to use the functionality "out of the box", because they are not developers and would not learn to use or improve the functionality without the example. === Other systems refer to a subset of the "multiple parents" functionality as "categories". Example: A document about "Apache Lenya " can be assigned "Apache", "Lenya", "CMS", "web software", "Java", "XML", etc. and would appear under each of the categories. This functionality would be more powerful in Lenya, because: - documents can be built from the children. - categories exist at any level. - our categories are documents (until we implement "menu-only" documents, and even then using this functionality will be more powerful than in most CMSes.) solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
