Jeremy Quinn wrote:
> At 11:49 am +0100 16/3/02, Torsten Curdt wrote:
>
>>Jeremy, I don't want to spoil your enthusiasm but there still two major
>>issues... I've been talking with Ivelin off the list about these issues.
>>(Maybe we should move our discussion to the list?!)
>>
>>1) current binding prohibits the use of checkboxes (good old checkbox
>> problem *sigh*) You cannot turn the checkbox off via request.
>>
>
> I am taking a different approach, it should not be a problem in
> <slash-edit/>; you have to supply (very simple) StyleSheet snippets to
> convert _your_ incoming request data into an instance to be validated.
>
> This gives you the opportunity to detect a missing field (un-checked box),
> because your StyleSheet should know about it.
exactly... that's the trick. but I didn't get your idea about the
stylesheet snippets yet though...
> There are two samples of this happening, one for the StreamGenerator, and
> one for the RequestGenerator, it could easily be done in XSP too, depending
> on your taste.
Where do you mean exactly? *puzzled*
>>2) AFAIU validation happens inside the XSLT transformer. IMHO this should
>> happen inside an action. Otherwise we have to choose what page to show
>> from the XML *content*. Only way I see do this is to create another
>> transformer for this. But still you are not able to react on the
>> validation result inside the sitemap... Or am I missing here something?
>> (Could a transformer set a request attribute that can become available
>> in the sitemap?)
>>
>
> I do not think you can easily send data back to the sitemap, though I am
> not needing to do that .....
now you see me curious....
> The scheme I am working on uses several Transformers and XSLT along the
> pipeline to adapt the XML according to what needs to be done to it.
>
> For instance, after the validation XSLT has run, another XSLT checks for
> generated errors. If there are none, the instance content is wrapped with
> the appropriate <source:write/> and the <validationResult/> is discarded.
> Otherwise, the instance is not wrapped, the <validationResult/> is left,
> but the behaviour is changed to 'get', meaning 'editor2html.xsl' XSLT will
> generate a form from your instance, to show the user again, with errors
> appropriately displayed.
>
> Next in line is the SourceWritingTransformer, there may or may not be a job
> for it to do ..... this is dependant on the tags in the stream. No need for
> conditional sitemap components.
Well, sounds good for a single page form (as well as Ivelin stuff yet)
but as soon as we have mulitple pages I see the sitemap and involved.
<snip/>
>>Currently I am trying to merge Ivelin work what I'm am currently working
>>on. I hope I can present this in a few days to the list...
>>
>
> With any luck I'll get this finished today, you can see what I mean.
I'm currious but still a little skeptic...
I currently already have a proof-of-concept prototype but it's not yet
ready for prime time. I see all this more like this:
let's say we want to have an instance (MODEL):
<userform>
<username>Torsten</username>
<email>[EMAIL PROTECTED]</email>
</userform>
I want this model to be represented in either in XSD, relax-ng or
whatever you like. The store will be an instance implementation like
- DOMInstance
- BeanInstance
then we have views for each page in the wizard / multipage form (VIEW):
page1.xml:
<form>
<textbox ref="userform/username"/>
<button method="next"/>
</form>
page2.xml
<form>
<textbox ref="userform/email"/>
<button method="save"/>
</form>
Now I still see actions as the CONTROLLER of choice. The buttons map to
an action defining what to be saved into the instance. So we also don't
have the checkbox problem. Of course writing such an action should be as
simple as possible. For usual simple forms it should be even possible to
specify everything via a XML descriptor.
That's how I see things...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
