El mié, 21-09-2005 a las 18:12 +0200, Andreas Hartmann escribió: > J. Wolfgang Kaltz wrote: > > [...] > > > IMO it's the opposite, as kind of discussed a couple of days ago. > > A document is something presented to the user upon her request; this is > > the more usual terminology. > > I'd call this a page.
Hmm, a page is a single piece of paper (that is what I associate with it). A document can contain multiple pages. I more share Wolfgang view. > A document is IMO an atomic (non-aggregated) you say here non-aggregated. > static or dynamic resource. > The page can be generated by expanding includes inside the document, which > makes it look like it was assembled from various documents. Includes *are* aggregates! Not like in map:aggregate but they are aggregated (or included) content. > > > But the document need not correspond > > one-to-one to a physical resource managed by Lenya. Instead IMO a > > document should represent a view (selection) of n content nodes. That is a very good point. forrest:views are actually following this demand. It is an implementation of the J2EE "Dispatcher View" pattern. http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.view/resources/views/default.fv <forrest:contract name="content-main"> <forrest:properties contract="content-main"> <forrest:property name="content-main" nugget="get.body"> <url>#{$cocoon/parameters/getRequest}.body.xml</url> </forrest:property> </forrest:properties> </forrest:contract> Each view defines which content should be requested via a forrest:property. A forrest:contract provides the transformation. http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/content-main.ft <forrest:template xmlns:forrest="http://apache.org/forrest/templates/1.0"; format="xhtml" name="content-main" inputFormat="xsl" body="true" head="false"> <xsl:stylesheet version="1.1" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> <xsl:template name="content-main-body" > <xsl:param name="content-main"/> <xsl:comment>+ |start content-main +</xsl:comment> <xsl:copy-of select="$content-main/[EMAIL PROTECTED]'content']/[EMAIL PROTECTED]'content-main']/*"/> <xsl:comment>+ |end content-main +</xsl:comment> </xsl:template> </xsl:stylesheet> </forrest:template> Another example for a more complex transformation can be found http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/nav-section.ft?view=markup > > A > > content node has meta-data, in particular Lenya internal meta data (such > > as "resource type"). A document is what is presented to the user when > > she makes a request. Meta-data here is more along the lines of dublin > > core (although dublin core can also be used for the nodes) > Do we really need a 1:n mapping from documents to content nodes? I understood like: Every request can have meta-data but do not need them. Following the forrest:view > Wouldn't it be sufficient to allow documents to include other documents? relating to meta-data? > I have the feeling that adding another layer will add unnecessary complexity. > IMO CInclude / XInclude, backed up with repository logic for integrity > control, could be sufficient. I disagree layers, if well defined, reducing normally the complexity by hiding the underlying implementation and offering standardized ways of accessing content. > > IMO the choice "is a document visible in the navigation" can be either > > in a navigation model (which does not yet exist as such, at least in the > > default publication); or in the document. Viewing that as part of the > > meta-data is acceptable if you consider that the document is a view on N > > content pieces managed by Lenya, and not a physical resource. +1 > > If we are talking about redefining the data model anyway, I think we > > should take this opportunity to flexibilize it: in particular it should > > be possible to define a document as a collection of n content nodes (how > > else would we provide for content reuse, amongst other features ?) > > > > BTW this would also permit a more uniform handling of assets (as binary > > content nodes) +1 If I find time I want to implement forrest:views to a lenya pub and we could discuss this example. 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]
