On Monday 24 November 2003 7:31 am, Robin Berjon wrote: > Tod Harter wrote: > > On Wednesday 19 November 2003 3:39 am, Matt Sergeant wrote: > >>I'd also like to think about how we can extend > >>PerForm so people can create their own PerForm widgets, rather than > >>having to stick to the default ones we provide. > > > > You accomplish that with XSLT. > > That's one possible binding, another is to use XForms abstract UI > elements and bind them to actual widgets (using XSLT or other means). > Having an abstraction layer is useful as it means nothing in your forms > ever needs to deal with the presentation part. > > > It shouldn't be hard to construct an XML syntax which describes where to > > go next and translate that into form actions and related elements. I have > > code already which parces an XML 'binding language' and uses that > > information to build and populate a form on output and validate input and > > round-trip the data back into an XML data structure. Going from there to > > RDBMS is trivial. > > XForms does a fair part of that.
Yeah, I agree with you that the XForms syntax is fine. My current forms system has 2 syntaxes, one which describes a form in a purely abstract sense, just names each form element and basic logical facts about it like the maximum amount of data it should hold, what options exist if its an option group, etc. I don't even specify anything about implementation. Basically this just says "I want a place to input text and its going to be called 'foo' and the user won't be able to enter more than 42 characters" Then I have the binding language, which tells you what XMLSchema data type 'foo' is, and XPath expressions which describe how to get foo out of a data instance, back into a data instance, and where in the form it goes. Finally there is an XSLT stylesheet which transforms the whole form into an instantiation for whatever client environment you have, DHTML, PDF, etc. It is at that point that you decide if you want radio buttons or a single select box for your options, whether or not to use a textarea or a text type input field, etc. Its certainly not a perfect system, but it works OK and obviously XUL or client-side XForms would be good. Getting back XML from a form submit would be nice as well since the binding language deals with XPath I have to have server-side code pretend its a DOM instance, which is kind of silly but its all done with SAX so not a big deal. Same with the RDBMS side if its going there, I have to convert the results of a query into SAX events and vice versa to put the data back into the database. I would love to have a way to extend the form definition language to allow specification of the logic of an entire data entry sequence. I guess thats what Cocoon is trying to do with their flow stuff. It shouldn't be all that difficult really, you just need a way to know where in the flow you are at any particular point and then be able to specify how you decide where to go next. Really its just XSP, but maybe a more domain-specific syntax could be pre-processed via XSLT to generate an XSP page that handles a particular flow. I think that would work pretty well. The only issue then remaining is the 'XSLT preceeding XSP performance' question. -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
