hi everyone!
currently, lenya is heavily document-centric and assumes "one file per
webpage".
this paradigm makes it quite hard to integrate database queries or
aggregate data from multiple data-centric documents. such tasks are
currently done directly on the cocoon level, or with custom lenya
resource-types. in either case, you lose the benefits of lenya and are
programming on the "bare metal" of web applications ;)
i would like to propose some new infrastructure to ease the integration
and aggregation of data sources:
1. an xslt resource type module.
it would be nice to handle xslts as documents, edit, download and
upload them via the gui, and benefit from revision control.
2. a "stylesheet" metadata field for each lenya document.
it allows to apply a custom stylesheet to a single document (in
addition to any stylesheets the resource type may apply already).
3. an aggregation resouce type module.
it contains xml that defines which sources should be queried and
aggregated, like so:
<aggregate>
<part src="lenyadoc://somerawcontent"/>
<part src="cocoon://modules/xhtml/someprocessedcontent"/>
<part src="cocoon://modules/xquery/somedatabasestuff"/>
</aggregate>
this file is then parsed, the sources resolved, the content
aggregated and passed to a custom stylesheet as defined in (2).
4. a couple of data-centric resource type modules as examples, such as:
* an xpath-query doctype that allows to filter arbitrary data out of
xml data documents.
* an xquery doctype that talks to xml databases
* an esql doctype that handles embedded sql queries
documents of this type would contain a query, and return the results
when processed. that way, you can edit and develop your queries with
revision control and without breaking the "live" version while you
tinker in "authoring".
do you think this might be generally useful?
can you spot problems, or suggest improvements?
your comments are very welcome.
*.*
implementation issues:
some of these points already sit on my disk in
so-far-pre-alpha-i-don't-have-a number-for-it versions:
(1) is basically the resource doctype, with an additional xslt rng for
validation and a special mime-type "application/xml+xslt" so that xslts
can be easily found among the other resources.
(2) is a single xconf with a custom metadata set.
(3) is an xsp that does not quite work yet, because some resource type
modules don't have matchers for absolute addressing (i begin to
understand andreas' feelings about over-use of {page-envelope:*}).
should probably become a custom generator. we need to define the
contract of resource type modules with the outside world more explicitly.
(at first i had this totally brilliant idea to store a complete sitemap
with an aggregator pipeline as a lenya document and mount it dynamically
into the module sitemap. which of course does not work. completely
erratic behaviour due to caching issues. i have written off the two days
i spent on that and put myself in detention to write a hundred times
"cocoon sitemap is not a programming language!".)
for (4), there is a prototype that talks to an exist-db instance. it
works but requires a custom handler on the other end, because cocoon
can't talk to plain REST services due to cinclude limitations... :(
regards,
jörn
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
