At 2:53 pm +0100 20/3/02, Nicola Ken Barozzi wrote:
>From: "Jeremy Quinn" <[EMAIL PROTECTED]>
>
>
>
>> At 1:51 pm +0100 20/3/02, Nicola Ken Barozzi wrote:
>> >Your needs are new to me, and highlight a possible deficiency in the
>> >handling of xml coming in.
>> >If we SAX away with it, we go in handle-errors.
>> >If we parse before, we do it twice.
>>
>> ?????
>
>If we validate the XML in a action, and then send the SAX events, it seems
>that we are doing two passes, ie two "parsings".
Ahh, OK, I am not currently using Actions for validation.
I generate a Schematron validating XSLT via an internal pipeline, which
validates XML in the stream and appends a report.
The XML to be validated has been previously generated either by the
StreamGenerator or the RequestGenerator from the submitted form, and
assembled into an "instance" of the updated document by an adaptor XSLT.
I agree an Action is an inconvenient place to do validation, because it
cannot output the xml it has generated from the form to be able to do the
check. So you are forced to either do it again (as you say), so you get the
XML in the Pipeline, or have a matching Transformer that will inject this
new XML into the Stream at the appropriate point, passing it "behind your
back" in a Session object or something.
One of the big problems IMHO of the attempts to make "the perfect form
handling implementation for Cocoon 2", is that before the arrival of the
WritableSource interface, people always had to choose a specific medium for
modification (File, SQLBlob, JavaBean, XML:DB etc etc.) so we end up with a
plethora of great ideas, spread around incompatible implementations.
Any of these (and more) could be re-implemented as WriteableSources and
invoked by a Transformer (SourceWritingTransformer, XIncludeTransformer
etc.) passing control of the actual Source to be used into the hands of the
SiteMap, not the implementation of an Action.
By breaking the tasks down we can re-use in more adaptive ways.
That does not mean I do not see the attractions of the various
implementations; I like the idea of having a single document that defines
the 'contract' for the form, in all aspects.
>If we make the pipeline do the validating, we mix the two phases (chacking
>and delivering the xml) and things get mixed up.
>IMV, we should use the pipeline only for content delivery, not for decisions
>(if possible, of course).
I think you will hate what I am doing then ;)
I am using (what I think of as) a Reactor/Adaptor pattern in XSLT on the
Stream.
Generated XML, is passed through a sequence of single purpose Transformers
(mostly XSLT).
These Transformers react to conditions in the Stream (existence of certain
tags etc.) and adapt the output according to simple logic rules; thereby
effecting the behaviour of subsequent Transformers in the pipeline.
<snip/>
>> >> The <slash-edit/> sitemap is broken down into small snippets that call
>> >each
>> >> other internally. If these internal pipelines could report errors in a
>> >> controlled way, it would be much easier to control the response.
>> >
>> >This is a *very* interesting point.
>> >
>> >You are using sitemaps as flowmaps.
>>
>> Kind of I guess ....
>
>Which is stunning BTW :-)
Thanks!! I am really having fun with it!
>I think you are the first one to stress the pipeline to its limits, and your
>editor could be the POC app for the future flowmap.
Gosh! Unexpected result ;)
>> >Thank you for slash edit.
>> >I think it's very cool :-)
>>
>> I stand on the shoulders of others.
>
>We all do.
>
>Chicken and egg ;-)
I just won't count them yet ..... :)
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]
