Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>> Thorsten Scherler wrote:
> From my POV, the major benefits of JCR vs. the others are:
>
> - You get a Java API and can choose your implementation.
> - You get versioning and transactions out of the box.
> - You can do XPath queries, which IMO fits our XML-based approach.
last thing i heard was that xpath support sucked, but that was 1.5 years
ago and things may have improved now.
> - JCR was designed for content management. There are best practises.
all good points.
>> i don't like how we are using a gazillion input modules and passing way
>> too many params to our xslts. i'd prefer to get at lenya-internal data
>> in big xml chunks which i then aggregate with the content and match in
>> xslts.
>
> We had that in 1.2 (page envelope). There are some major performance
> drawbacks:
>
> - You need to compute everyting up front.
true.
> - You have to compute the data for each "parallel" pipeline (e.g., for
> navigation elements and XML chunks which are called using XInclude).
> This generates a lot of XML, and therefore SAX+XSLT processing overhead.
caching should take care of that. and i don't see why they should have
to be computed more than once per request (i know they are now). still,
a valid concern.
> IMO a transformer is (in most cases) the most appropriate technology to
> feed data into the SAX stream:
>
> - It doesn't clutter the sitemaps like input modules.
> - It provides data on demand, only if they are requested by the
> processed XML.
+1
>> for instance, i'd like to be able to say "give me this file's revision
>> history for the last n revs" and "give me a map of user ids vs. their
>> emails", and then i can implement the "last edited by user
>> <[EMAIL PROTECTED]>" stuff in my xsl, where it's easy to see and understand.
>
> These cases could be handled by a transformer:
>
> 1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
>
> would be expanded to
>
> <rev:history document="...">
> <rev:revision ...
> <rev:revision ...
> ...
> </rev:history>
>
> which can be evaluated by a subsequent XSLT.
lovely. imho, this is the most natural way of dealing with it.
unfortunately, lenya uses this pattern only in some obscure corner
cases. we should change that.
> 2) <ac:insert-user-data user="{$currentUser}"/>
>
> would be expanded to
>
> <ac:user-data user="john">
> <ac:email>[EMAIL PROTECTED]</ac:email>
> <ac:name>John</ac:name>
> ...
> </ac:user-data>
>
>
> [...]
>
>> if we somehow exported an xml view of our repository, i'm sure many
>> users could think of very clever things to do with their content and
>> metadata.
>
> In principle I agree, though I'd rather provide a well-documented and
> extensible set of "custom Lenya tags" (see above). AFAIK most CMSs
> provide such a mechanism, and users are used to it. A big plus of Lenya
> is that, thanks to Cocoon, we have XML processing pipelines which allow
> very flexible and powerful tag expansion scenarios.
sounds good. we should bear in mind that users might want to do things
we haven't anticipated, and expose everything in a generic way. i know
that's contrary to the oo philosophy of encapsulation, but oo is not the
holy grail, especially in realms where scripting languages are totally
adequate.
i'd say we should do strict interfaces and encapsulation for writing
data and doing access control, and be really sloppy when it comes to
retrieving data.
> (Regarding the workflow engine I have no strong opinion at the moment,
> only that it would be nice to have workflow-driven usecases instead of
> the other way round as it is now.)
well said. thorsten, what made you mention workflow explicitly? do you
see problems with our workflow engine that other engines could solve? we
should really find a way to get better error messages, but i'm not sure
external code could do that easily.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
