El mar, 10-01-2006 a las 12:46 -0500, [EMAIL PROTECTED] escribió:
> 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).
>
Actually what I understood from Wolgang and I support is that with JCR
comes the change to totally separate the content storage (repository)
from our publication concept - especially how we define which content
should be used in the pub.
A publication is an aggregation/edition of certain documents from the
rep. You can compare it with a magazine. A magazine contains certain
articles.
This articles may be reused in
a) different editions
b) different magazines
Further the table of content (toc) of a magazine can be compared to our
sitetree.xml. Here we define which articles/documents our publication
contains and how it is structured hierarchical.
That said the toc mechanism (sitetree.xml) should be separated from the
rep. In the rep the articles may have a different storage philosophy
then in a publication.
Let us say in the rep we store the articles in a topic related way. Like
article "bmw-x3" is a car review and would be stored in the rep like
/reviews/cars/bmw-x3
Now in our magazine/publication "Ultimate Car" edition 01/2006 we are
using this article. What we would have is "just" a reference to
"/reviews/cars/bmw-x3" in the toc where we want to present the article
in our edition.
<node id="last-reviews">
<node id="introduction"
uri="/ultimate-car/2006-01/last-reviews/intro>
<node id="article-a" uri="/reviews/cars/bmw-x3"/>
</node>
You see that an edition may provide edition specific content
(id="introduction") and global content. It is just a edition "view" on
the repository.
In another magazine/publication "lifestyle" edition 02/2006 we are using
the review again.
<node id="current-trends">
<node id="fashion" uri="/reviews/fashion/dior-2006-01>
<node id="article-a" uri="/reviews/cars/bmw-x3"/>
</node>
In jcr we may store all this like:
jcr
|--content
| |--docId-xy
| `--docId-yz
|--publication
| |--ultimate-car
| | `--2006
| | `--01
| | `--intro
| |--lifestyle
...
|--logical-storage
| |--authoring
| | `--reviews
| | |--cars
| | | `--bmw-x3 -> docId-xy
| | `--fashion
| | `--dior-2006-01 -> docId-yz
...
Where "->" would be a symbolic link (like in unix "ln -s").
> 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.
>
Agree
> 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.
Given above example, how does the index look like?
> 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.
>
Like seeing above, the document id within a publication
(/ultimate-car/2006-01/last-reviews/article-a) will differ from the one
in the rep. In the logical store it would be e.g.
"/live/reviews/cars/bmw-x3" which is linked to the flat content node
"docId-xy".
> > 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)
>
You can store this as profile data as well in the rep.
> 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.
>
I like it as well, still trying to understand the full consequences. ;-)
> > 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?
>
Yes, if we do it we should use the default pub as testing area.
> > > 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.
>
Paul is right this feature need to go into the feature set of the
default pub. Still we need to keep in the back of our mind that we have
to find a balance out of full-blown-away showcase and maintenance
optimized feature presentation. With the new module architecture we can
easier maintain the example code but we still need to maintain it. ;-)
> ===
> 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.)
:)
See above example, I totally agree that this is needed.
>
> solprovider
Good stuff, solprovider. Thanks for pushing this.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
