Konstantin,
Thanks for responding. I know you're knee deep in forrest work ! > > Since the all XML/XSL form validation and presentation is > > already available > > and somewhat useful, as Jeremy demoed, > > I would now like to do the all Java extreme. > > I got the Schematron validation of JavaBeans/DOM working with > > XSL templates, > > but I decided to implement an even more efficient JXPath > > based schematron > > validation. > > I would also like to line up with Torsten (and your) > > preference of the XForm > > style. > > That's great! Did you have a chance to look at the new demo? > I've attached my XForms sample, it contains an XForms.xml with a form > description, data bindings and instance data. The second file - XForms.xsl - > is a stylesheet that ties all that stuff together then displays as HTML. It > requires Xalan 2.3 (2.2 has a bug) to run (I've used Xalan extension for > dynamic XPath evaluations that were required). I like your XSLT! I agree that it is will be useful to allow people to use XForm "as common markup for the forms". [Berin, does that quote sound familiar ;) http://lists.w3.org/Archives/Public/www-forms/2001Mar/0033.html] This could lead to shared best practices in writing forms and also serve as a transition path to XForms aware clients. Are you interested in extending your stylesheet to be a bit more generic and allow for visualisation hooks. For example I would like to be able to import your stylesheet and override some templates which will render the forms in a way more appropriate for my web UI color scheme and layout. These are the parts of XForms that make sence to me for server side implementation, although a complete server side implementation is simply inpractical. XForms events are simply unreal for server side impl because of the roundtrip cost. Actions and validation are also nice for a client side implementation, but not good if roundtrip is required. However the data binding part is useful, and that's where we can focus. As long as your stylesheet takes an instance (inserted in the XForms document from a JavaBean or DOM node through CastorTransformer or a flat XML file) and renders HTML Form with element names which correspond to the XPath locations of the instance elements, then I think it can be a perfect match to the CocoonForm toolkit I built in the last few weeks. It will be probably a good fit for Torsten's framework which we'll eventually integrate with. Appears that your current work is very close to achieving that. Another fundamental problem is nested and overlapping forms. Realisticly, these are just unpredictable when it comes to HTML. HTML 4.0 is not going away soon and XHTML 1.0 is still to be widely adopted, but even it doesn't understand XForms. On this one I think it is a quite safe bet to allow one XForms instance per transformation. This will ensure HTML forms aren't merged, while at the same time allowing multple form per HTML page. So to summarize: XForm markup is good for uniformness. XForm Actions, Events, validation and nesting should be left out for the days when clients will support those. With the Schematron libs we now have, we're pretty well covered with server side validation, don't you think? It would be cool if Berin (as an ExFormula developer) and the folks who build Chiba participate in this discussion. They've already spent a significant amount of effort on this problem. If we're to solve it and bump Cocoon to the level of Struts and the next generation Java Server Faces based app servers, we need their help. > Btw, does your validation code take into account the field-set of the > current form? I think that it would help to solve the problem with > 'phase-based' validation. Having information about the visible (or relevant) > fields for the current request will allow to perform partial validation of > the data. But here comes another issue: on what event to perform the full > validation, including dependency checks? Maybe different validation rules > depending on the user actions (or, maybe it's better to call them events: > input, finish, cancel, etc.)? In this case you would name the phases after the pages in the wizard. The "input" phase will activate the patterns for the fields in the first page, "finish" will activate all patterns and "cancel" will not do validation at all. See how the new demo uses phases. Does that help? Cheers, Ivelin > > I would also like to encourage readers to see Torsten's code > > and share their > > thoughts on how they'd like to see form binding/validation > > done in Cocoon. > > As the general lesson of live states, if you want to see > > something done in a > > way you like, say it ! > > Ok. > > Konstantin > > > > > Ivelin > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, email: [EMAIL PROTECTED] > > > > ---------------------------------------------------------------------------- ---- > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
