> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 6:45 AM > To: [EMAIL PROTECTED] > Subject: Re: Cocoon Form binding and validation [was: RE: > SchemoX forms] > > Konstantin, > > > Thanks for responding. I know you're knee deep in forrest work !
Not at all. Thank you for your work. I've been concentrating on Cocoon release and i18n and JSP samples/docs, so I hadn't time even to see latest updates to Forrest. Now when release is issued (with non-working JSP samples and outdated i18n docs!) I had time to look at your sample. > > > > > 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? Yes, although I didn't go deep into the source. > > > 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! Me too ;) > 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. It was just a sample of how a form in XForms markup can be displayed, but I tried to keep it rather generic forseeing the need for overriding. The most custom template is 'group' template as I remember, you can override it to generate a custom layout (I have attached a sample for that: groups are presented with 'div's and not tables). Colors can be customized by CSS (it's embedded now, but I will move it to an external file). Error messages layout is a little more complicated thing. Customizing it will require duplication of templates for all the input fields. Although as soon as I have a little free time I'll concentrate on your application to make it look a little better and more real-life. What about a wizard for customer registration? Scenario: - Enter Personal Info (name, date of birth) - Enter Contact/Address Info (phone(s), address) - Confirm registration (a page, that displays all the entered information and two buttons 'Confirm' and 'Cancel') - A success/error pages User should be able to navigate forward and back between first two forms and cancel the process in every state (except, of course, success page). > > 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. Actions, events and validation would be possible on the client side if JavaScript had XPath/XML capabilities, but implementing it (even a simplified version) would require a lot of time and I gave it up, although you can see some hooks for 'relevant' attribute in my sample. Try to change instance data to make car info relevant and you'll get according fields enabled. Microsoft IE (5.0+) has built-in ActiveX for DOM parsing and maybe XPath evaluation with JavaScript, but it's too browser specific, although it's a great feature. > > However the data binding part is useful, and that's where we > can focus. Yes, I'm agree with you, although the most useful part of XForms is its event model. > 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. I'll further my work on that (although, I can be back to my paid work at any time and I don't want to leave unfinished stuff). If Torsten's work in CVS then I'll take a look at it. > > Another fundamental problem is nested and overlapping forms. What is the practical use for nested or overlapping forms? I can understand 'nested' as a sub-set of fields that can be submitted independently (I think this can be achieved with 'relevant' attribute or 'submitInfo' descriptor), but what are 'overlapped' 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. In XForms specification I haven't seen any 'form' element, all field grouping is processed using 'group' and 'submitInfo' elements. So, did I get you right, that the question is 'how do we generate HTML forms based on XForms markup'? > > 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. Agree. We'll try to implement everything that is possible on the server side. > With the Schematron libs we now have, we're pretty well > covered with server > side validation, don't you think? If it supports dependecy checks then 'yes'. An example: is it possible to implement such a validation rule "validate 'car-model' required field only if the user indicated that he owns one (has set 'has-car' field to true)"? > > 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. We need to create a small but real-life sample application and we will achieve the level of Struts. Haven't look at JSF, but it's based on Struts, isn't it? > > > 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? Yes, I this is what I've been looking for, although, the implementation is a little different from what I wanted. So, let's start work on a web app now! Your work fills me with enthusiasm ;) Regards, Konstantin > > > 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] >
Custom.xsl
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
