Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <008f01c1d189$1c853060$34c83ed8@galina>
Reply-To: "Ivelin Ivanov" <ivelin@sbcglobal.net>
From: "Ivelin Ivanov" <ivelin@iname.com>
To: <cocoon-dev@xml.apache.org>
References: <a05101401b8bcb2c82cf6@[10.0.1.40]>
 <006701c1cf2d$ffc827f0$670004c0@PC103> <a05101400b8bce7a51c7f@[10.0.1.40]>
 <026301c1cf49$9db98d30$670004c0@PC103>
 <a05101402b8be0dbe98d4@[161.74.104.156]>
 <004d01c1d00d$f15c39f0$670004c0@PC103> <a05101407b8be3e20efcb@[10.0.1.40]>
 <00cf01c1d016$a47a4920$670004c0@PC103> <a0510140bb8be47ab2c79@[10.0.1.40]>
Subject: Re: error handling !*#%!
Date: Fri, 22 Mar 2002 04:05:35 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Just a quick update.

I am hammering on the Schematron Validator.
Have it working already, but am now trying to optimize it to be all SAX
based and use XSLTC templates.

Should be ready any day now.

> 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.

The Schematron validator I'm working on now, takes a JavaBean as input and
returns a ValidationResult JavaBean
with all the information you'd find in a validationResult document.
The Action is free to choose what to do with the errors. The form bean and
the validation result can be inserted in the pipeline through the
CastorTransformer and used for the HTML page. Validation does not have to be
repeated.

I guess this will just give people alternative ways to do validation, while
allowing the validation rules to be kept in a central place - Schematron
schema. Torsten is going to offer a similar solution for Relax-NG schemas,
for those who prefer Relax-NG. If there's enough interest, we may do XML
Schema validators.


>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:sharkbait@mac.com>     <http://www.media.demon.co.uk>
>    <phone:+44.[0].20.7737.6831>             <pager:jermq@vizzavi.net>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org