Most of my answers below are not about "Multiple Parents". The
ability to assign multiple parents to a document so it appears as
children of several documents is an optional extension of my
suggestions for structural changes.
On 1/11/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
> 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.
I am not certain that will still apply. I think of a Publication as
common functionality applied to common documents. Document selection
(subsetting) will be handled better with indexes/views/filters.
We seem to be moving to most functionality being handled by global
modules and Pubs using a common datastore, but I think the ability to
override global functionality at the Publication level is too
important to remove the Publication layer. Publications may
eventually be a list of Documents, the indexes, and a few XSL files
that override the default XSL files in the "live" module.
> 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.
How often is it useful for a Document to be part of multiple
Publications? What is the business reason for not just copying it?
As I discuss later in much detail, if Documents are being shared, why
are they separate Publications?
> 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").
In other discussions, I have suggested consolidating the content by
document, with the versions kept under the document so there is no
need for an "authoring" storage area. Corrupting your example, it
would look like:
jcr
|--content
| |--docId-112 (live="version3", authoring = "version3")
| | |--version1 (status = "published-obsolete")
| | |--version2 (status = "published-obsolete")
| | `--version3 (status = "live")
| `--docId-113 (live = "version2", authoring = "version3")
| | |--version1 (status = "published-obsolete")
| | |--version2 (status = "live")
| | `--version3 (status = "draft" or "waiting for approval")
| `--docId-114 (live = "none", authoring = "version1")
| | |--version1 (status = "draft" or "waiting for approval")
|--index (publication - single parent)
| |--ultimate-car -> doc111
| | `--2006 -> doc112
| | `--01 -->doc113
| | `--intro --> doc114 (authoring only, not live)
| |--lifestyle --> doc115
|--index (publication - multiple parents)
| |--ultimate-car -> doc111
| | `--2006 -> doc112
| | `--01 -->doc113
| | `--intro --> doc114
| |--lifestyle --> doc115
| | `--2006 -> doc112
Where "->" uses the UNID to refer to the document in the flat storage.
Is there a reason for a separate index for "authoring"? A flat view
of all documents can be created from the content (which has many uses
such as filtering on "waiting for approval"). The hierarchical
authoring view can use the same index as the hierarchical live view,
if the indexes support selection flags; just use a flag in the index
for "not live". The documents should use the same hierarchy (unless
we want to support workflow for moving documents in the hierarchy
Nobody has proposed that yet, and it feels like too much work for no
value.)
> > 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?
The index would be the same as above. The important part is to make
selection filters easy. When walking the index, the index entry
allows access to the Document Properties and Children. It should be
more powerful than the current structure.
discussion2xhtml.xsl would access the children nodes:
<body>
<xsl:apply-templates select="xhtml:[EMAIL PROTECTED] = 'menu']"
mode="menu"/>
<xsl:apply-templates select="childNodes()"/>
</body>
<!-- Add Child BlogEntry to document -->
<xsl:template select="@doctype = 'BlogEntry'">
By <xsl:value-of select=".//author'"> on <xsl:value-of select=".//creationdate">
<xsl:value-of select=".//[EMAIL PROTECTED]'body'">
</xsl:template>
<!-- Remove BlogEntry from menu -->
<xsl:template select="@doctype = 'BlogEntry'/" mode="menu"/>
Implementation detail: To make that possible, must the XML for
children be included in the XML for the parent (easy, but wastes
resources)? Or can we make a function like childnodes() that adds the
XML as needed (difficult, but more efficient)? Is it possible to have
a placeholder that retrieves more XML and adds it during the XSL
processing?
> > 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".
Are you saying there one repository for a Lenya server? I expected
one repository per publication. Either way, a document should have
one and only one Unique Identifier (UNID). Publications would have
their own indexes to decide which Documents belong. If there is only
one content repository per server, we must decide how the Documents
are organized.
1. Lenya/Publication/Content/Documents keeps each Pub's Documents in
their own tree. A Document entry cannot belong to more than one
Publication, although it could be copied. This simulates having
separate repositories for each Pub, but makes Softlinks easy. A
Softlink could override some of the properties of the target document,
such as the ParentUNID, and the workflow fields. (This allow Version2
to be live for PubA, and Version4 to be live for PubB. Edits happen
on Version7 for both Pubs.)
2. Lenya/Content/Documents keeps all Documents together so they can be
reused across Publications. There are many issues with this
structure:
- Extra indexes for each Publication's flat view for which Documents
belong to this Publication.
- The ParentDocument property would need to be assigned for each
Publication because the parent Document may not exist in a Pub that a
child Document does.
- Documents could exist that are not assigned to any Publication.
#2 does add flexibility, but programming and maintenance would be
difficult. Proper use of modules will add much functionality within a
Publication. I cannot think of any functional reason to have multiple
Publications. A little proxying handles different homepages for
different websites with the same content. Multiple "live" modules
handles different look-and-feels. Adding another index selects
different Documents. If content is to be shared, there should be only
one Publication.
> > > 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.
> > > 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.
Completely off-topic, but I would really like User documents to allow
additional fields. In Lenya 1.2, I overloaded the Description field
to store personal data because it was the only non-functional field,
and there was no method to add and access non-standard fields. A
flexible "profile" stored in the User would be great (and really easy
to code.)
> [About the default publication] 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.
If the structure is mostly static, modules will last forever with
little maintenance. The following expected improvements should give
us a mature platform once it works and the early bugs are fixed:
- JCR content repository
- flat document storage
- flexible indexes with easy filtering
- modules for code separation
- all functionality in modules (including live, authoring, workflow, etc.)
- full and partial fallback for modules (so minor changes to one file
do not require copying the entire module.)
- removal of Ant, and reduction of technologies.
When this is done, I will add an Authoring module with all Document
information on one page. It will co-exist with the tabbed Authoring
module. A simple menu switches between them, and the Kupu and BXE
modules for editing content. Adding other editors will be easy, and
upgrading one of them would require editing only one module with all
the code in one place.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
