cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: XML Form use cases
Date Mon, 21 Apr 2003 16:24:57 GMT

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:

                   function(xform) {
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.



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
>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'
>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
>- 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>

View raw message