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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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:[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
