At 12:44 pm +0200 11/4/02, Ulrich Mayring wrote:
>Jeremy Quinn wrote:
>>
>> During the 'put' phase in <slash-edit/>, the instance, having been
>> assembled from the Request by an XSLT, it is then processed with the
>> generated Validator XSLT.
>>
>> Next an 'adaptor' XSLT checks there were no Validation errors before
>> wrapping the instance in a <source:write/> tag so that the
>> SourceWritingTransformer (later in the pipeline) can output it to the
>> Source.
>>
>> Is it these tiny, one-job adaptor XSLTs and the logic they perform causing
>> you these problems, or is it the whole concept of incrementally adapting
>> content in the pipeline?
>
>It seems to be a fairly procedural approach and, while I have not seen
>what these XSLT stylesheets do exactly, they appear to work in a fairly
>deterministic way.
Have a look ;)
Keep in mind it is work in progress ....
>XSLT is not ideal for procedural algorithms, but at
>the end of the day it's just another language. There is a tradeoff
>between doing things in a less-then-ideal, but available language
>compared to an ideal, but less-than-available language. If you use XSLT
>just for two internal things, the tradeoff may be on your side, if your
>users start to write their own XSLT stylesheets to configure the
>process, then perhaps the tradeoff falls on the other side. YMMV :)
I am gradually separating out the XSLTs that are 'inherent' ie. don't need
to be touched because they are part of the way slash-edit works, and those
that the 'user' legitimately needs to modify for themselves.
Any contracts in the 'inherent' XSLT can be firmed up, in terms of the
<editor/> DTD (the way it 'carries' the Instance, config and reports
errors), and the messages received from the SiteMap. These components can
be implemented in Java as and when necessary.
At the moment, the 'user' has to modify certain files to:
(1) Handle their own DTD and namespaces
the XSLT to convert the Request data into the Instance
the XSLT for converting the Instance into a Form
the Schematron document for validating their Instance
(2) Provide their own style
The next step could be to turn both XSLT aspects of (1) into a set of
generic Transformations that share a config file for both operations, then
potentially this could be implemented in Java.
Or instead of implementing any of this XSLT as Java, we could treat it like
we treat logicsheets, compile them into the cocoon.jar and access them as
resources.
Thanks for your interest
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
