cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@iname.com>
Subject Re: [Announcement] HTML Form binding and validation arrived
Date Sat, 16 Mar 2002 19:13:56 GMT

It took me a while to digest your solution.
Now that I think I understand it basicly, it seems elegant.
I would appreciate to see some sample code though.

You're welcome to join our discussion with Torsten, so that we can finish a
complex wizard that can server as a best practices example.

Thanks.

----- Original Message -----
From: "Jeremy Quinn" <jeremy@media.demon.co.uk>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, March 15, 2002 5:06 AM
Subject: Re: [Announcement] HTML Form binding and validation arrived


> At 6:44 pm -0600 14/3/02, Ivelin Ivanov wrote:
> >For the wizard I would like to do the following, but am not sure what's
the
> >optimal way to express it with a sitemap.
> >Maybe you can help:
>
> this is still a difficult issue ....
>
> >1) When the browser request an URL with HTML form, then the pipeline in
the
> >current example works fine.
> >2) Now when the browser submits the form though, I would like to pass
> >through the same (or similar) pipeline, but at the end, instead of going
> >back to the same page, I'd like to forward to another Action2 if there
are
> >no errors in the <validationResult/> section of the <xmlform/> stream.
> >3) Action2 will then do additional business logic validation and will
either
> >  a) branch to a pipeline which produces <xmlform/> with
<validationResult/>
> >section that contains <errors/> and is followed by the same
transformation
> >which happen in 1) to display the html form page with the errors
> >  b) call into business logic to perform additional work and branch to
the
> >next page in the wizard.
> >
> >What is the *right* way to branch at the end of step 2), 3.a) and 3.b)?
>
> The problem as I understand it here is that all Actions in a pipeline are
> executed before any pipeline processing is commenced. (This still seems
> weird to me;)
>
> >These questions maybe overlapping somewhat with the other thread on
dynamic
> >pipeline selectors which is going in parallel. Anyway,
>
> This is something I am beginning to play with in <slash-edit/>.
>
> The general idea is this: (I don't know if I can express this in terms
> immediately useful to you ....)
>
>
> <slash-edit/> uses aggregation to assemble document parts, the aggregation
> creates tags that "instruct" later XSLT passes what to do.
>
> XSLTs in the pipeline act as "Adaptors", conditionally modifying the XML
> according to different runtime states, to modify the behaviour of later
> XSLT and Transformers. (This is the key, your business logic would have to
> be implemented in a Transformer).
>
> As an example, let's say I had Schematron validation in <slash-edit/>.
>
> The internal "fetch-put(*)" pipeline, would capture the request, XSLT
would
> convert it to your document instance, your schematron.xsl would produce a
> validation report, another XSLT (editorAdaptor) would adapt the whole lot
> for the Editor, if there were no validation errors, it would wrap the
> instance in a <source:write/> tag so the SourceWritingTransformer would
> write it, if there were errors, it would not wrap with <source:write/>,
> meaning that even though SWT is still in the pipeline, it does nothing. On
> error editorAdaptor, could then change the behaviour from 'put' to 'get',
> meaning that editor-html.xsl would convert your instance back into form
> again for re-editing.
>
> Does this make any sense?
>
>
> 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


Mime
View raw message