cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: [Announcement] HTML Form binding and validation arrived
Date Fri, 15 Mar 2002 11:06:36 GMT
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


Mime
View raw message