cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johan Stuyts" <jo...@hippo.nl>
Subject RE: XML Form use cases
Date Thu, 24 Apr 2003 09:25:25 GMT
Thanks for the changes. Unfortunately I haven't been able to use them
yet, but I will soon.

At our company we are very interested in what needs to be changed of
XMLForm. Could you elaborate on where XMLForm is non-conformant the
XForms specification? What do you think the timeframe for the release of
the new version is?

If you need any help we are willing to contribute.

Johan Stuyts
johan(at)hippo(dot)nl / www.hippo.nl 

> -----Original Message-----
> From: Christopher Oliver [mailto:res1cf5x@verizon.net]
> Posted At: Monday, April 21, 2003 6:25 PM
> Posted To: Cocoon Dev List
> Conversation: XML Form use cases
> Subject: Re: XML Form use cases
> 
> Johan,
> 
> Thanks for taking the time to describe these use cases. For
multi-button
> forms I've modified XMLFormTransformer so that it preserves the submit
> id (instead of overwriting it with the continuation id). That way
you'll
> still at least be able to find out which button was pressed. I've
added
> a getSubmitId() function to XForm, so you can now find out which
button
> was pressed in your flow script:
> 
> xform.sendView("userIdentity",
>                    "flow/userIdentity.xml",
>                    function(xform) {
>              print("button="+xform.getSubmitId());
>           });
> 
> However, I'm hesitant to fully address your use cases at this point
> because I think XMLForm needs to be updated to be in line with the
more
> recent W3 specification, before we can design a solution -- since that
> will result in non-backward-compatible changes to XMLForm that would
> affect any design we came up with now.
> 
> Regards,
> 
> Chris
> 
> 
> 
> 
> Johan Stuyts wrote:
> 
> >At our company we are going to use XMLForm & Flow to build an
> >application. It is working great, but we have run into some problems
(or
> >think we are going to) with the following use cases:
> >
> >
> >Use case A: Add an item to a list of items
> >----------
> >As part of a larger form the user can enter zero or more subitems.
> >Initially the form will have space for 'n' items, but the user must
be
> >able to add extra lines to the form. (e.g. a form with personal
details
> >with a list of favorite URLs)
> >
> >However, the validation that occurs on the form should not be
performed
> >when the 'add line' button is pressed, but should be performed when
the
> >final 'commit' button is pressed.
> >
> >
> >Use case B: A button per item
> >----------
> >A lot of forms contain lists. It is handy to add one or more buttons
to
> >each item sometimes. (e.g. a 'delete' button for each item in a
shopping
> >cart)
> >
> >
> >Use case C: Action buttons for different flows
> >----------
> >Some forms can have multiple submits which select different flows
> >through the application. (e.g. a login screen with a user name,
password
> >and 'login' button, and an email address and a 'send my login
details'
> >button)
> >
> >
> >To implement these use cases, it is necessary that the function that
> >calls 'sendView' is able to easily determine which button was
pressed.
> >For use case B it is also necessary to determine which button of the
> >same button 'type' was pressed.
> >
> >Use case A has been implemented with a modified version of
'sendView'.
> >It looks up the validation phase name to use using a Java Map which
gets
> >passed in instead of the validation phase name. The validation phase
> >name is looked up using the button caption. (Both the usage of a Java
> >Map and using the button caption for lookup are quick hacks)
> >
> >Here are some questions and thoughts:
> >- Should I use the 'cancel'-button construct which is mentioned in
the
> >comment of 'prepare()' of the Java action class of the XMLForm wizard
> >tutorial? If so, how do I use this in Flow?
> >- I think the 'id' attribute of a submit control in an XMLForm
> >definition should be added to the name of the HTML submit button. The
> >XMLForm (framework) should give easy access to this name after a
> >successful (no violations) submit.
> >- The repeated submit controls should have a number added to the name
of
> >the HTML submit button. The XMLForm (framework) should give easy
access
> >to this number too. I do not know whether this number should be
> >generated by the XMLForm framework. After which the user flow
function
> >must map the number to an object. Or whether it can be an object ID
> >supplied by the form document/bean.
> >- A map (JavaScript/Java/...) should be passed to 'sendView' instead
of
> >a validation phase name. The keys are the 'id' attributes of the
submit
> >controls in the XMLForm document. The values are the validation phase
> >names.
> >- Another thing I've been thinking about is forwarding or passing
> >through violations in the case of use case A. Suppose somebody tries
to
> >commit the data, but it is not complete. The same form will return
with
> >violations. If the person then adds an extra line to the subitems,
the
> >violations won't show up anymore because no (or limited) validation
is
> >done when adding a line. The person will only see the previous
> >violations when he tries to commit the data again. Would it be nice
to
> >specify blocking and non-blocking validation phases for a button?
e.g.
> >commit: blocking = completeForm; add line: blocking = noEmptyURLs &
> >non-blocking = completeForm
> >- How to perform validation for use case B is still unclear. It would
be
> >nice if only the item the submit control belongs to could be
validated.
> >Validation for the other items would be non-blocking.
> >
> >Johan Stuyts <johan at hippo dot nl>
> >www.hippo.nl
> >
> >
> >
> >
> 
> 



Mime
View raw message