cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: XML Form use cases
Date Sun, 27 Apr 2003 02:24:16 GMT
Ok, I've just checked a reimplementation of XMLForm (called JXForms) 
into the scratchpad that supports the W3 candidate recommendation's 
syntax (although not all of the form controls, at least not yet). It 
does support the same functionality as the existing XMLForm (and for the 
moment it still uses the Form and Validation components from XMLForm) 
with the exception of the "hidden" element.. It also supports nested 
"repeat" tags. It can be used as a generator (JXFormsGenerator) or 
transformer (JXFormsTransformer). There's also a sample of the feedback 
wizard in the scratchpad samples. Initially, I've integrated it with the 
flow layer in the same way as XMLForm, but we can now experiment with 
different approaches to solving the use cases you mentioned.

Regards,

Chris

Johan Stuyts wrote:

>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