Same thing for using the validation processor: if there is an unexpected behavior there, it should probably be fixed.
-Erik
[EMAIL PROTECTED] wrote:
Alex,
My topmost question is about error validation. How to go about it - what strategy to use (schema and/or bind statements). Firstly I am concerned with user interface validation secondly with validation of data in lower layer pipelines doing things like database manipulation.
Regarding the first issue, I have noticed two solutions in the examples: 1) using schema to validate xforms instance 2) using xforms:bind statements to do the validation.
The schema we built so far uses attributes for representing entity properties rather than child elements of parent entity elements (e.g name is an attribute of person rather than an element of person). This latter (having child elements) is actually what all of the examples I have seen uses. This made me suspicious that the design of our schema is not practical for either approach of input data validation after I tried both.
My experience showed that when I have specified a schema for the xforms instance document (similar to the Bizdoc example) my attributes were not checked (e.g. empty fields, date fields anything given is accepted and the check in the page-flow for the 'error' element is unsuccessful which results in normal continuation of the flow) and did not result in validation errors. When using child elements instead of attributes the validation works fine.
On the other hand if I am doing validation with bind statements I have two problems: 1) there is a nasty redundancy in the validation rules - even when nesting them - the validations are defined once on the element level once on the attributes; 2) I am redundantly redefining validations rules which are already there in the schema.
In addition to the above I also noticed with the bizdoc app that errors are shown one by one, when it would be a lot more workable for the user to see all in one iteration. Moreover messages should somehow be localized.
The above, the examples and your letter seemed to suggest to me that the way to go is to redefine our schema to not have attributes and use child elements instead. This is a critical question to decide right now before we have much too much code and data to retrofit.
Regarding the second issue (validation on lower layers of the application, e.g. db management) I guess the way to go is to use the validation processor, which I also tried. So far I got an error which seemed to say it cannot add an error element since there is already one. But I am not sure that my tests are correct, so I will continue with this once the user interface validation staff is in place.
cheers, Balázs
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
