On Tue, 2003-04-01 at 16:50, Bertrand Delacretaz wrote: > Le Mardi, 1 avr 2003, à 16:18 Europe/Zurich, Bruno Dumon a écrit : > > > ...It should be possible to create a form just by describing its > > structure > > in an XML file (lets call this a "form description"). I don't like the > > fact that for XMLForm/Struts the user needs to write a bean just to > > hold > > the form data... > > Maybe going all the way down to a kind of "data dictionary" that > describes the data model and tools to work with it would be even better? > > A while ago I suggested something along these lines > (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103786946103965&w=2), > there was little response at the time and I didn't follow with concrete > code but you might find it useful.
Very interesting, the approach with the "data-types" and "field-types" corresponds a lot with what I've been thinking of. > > I think you need three mappings to write a complete web application, > and these should ideally all derive from the same definitions (what I > call the data dictionary). Might not be doable right away, but > designing the dictionary for these uses could be very useful later on > (need to check the YAGNImeter though): > > -mapping from data to XML forms the 'data' would then be the beans? That's basically the one thing where we differ in approach: I would just let the fields remember their value, instead of requiring some bean here, so the data and the form are the same. > -mapping from request attributes to data (type conversions, key > lookups, etc.) > -bidirectional mapping from data to storage (database or XML) I see this last one as an optional and distinct part (not all forms are used to edit some entity), but definitely useful for crud-type applications. > > Not to mention other things that can also be stored in a data > dictionary, like internationalized fields names, links to help pages, > hints for acccessiblity, etc. Some of this belongs to forms, but a lot > of it is broader in range than forms, hence the idea of central > repository for this information, not limited to forms. > > Of course form definitions are needed at some point, but with a system > based on a data dictionary they could be very simple, just listing > which fields go in which form. Also useful when a field is used in > several forms. Yep, I think I agree with this datatype - formfield separation. > > > ...a FormInstance can be created, which is a lightweight data-structure > > that holds the instance-specific data for the form (the submitted > > values > > and the validation results). So this would avoid the need to create a > > bean, since from the user perspective, it would be as if the widgets > > themselves hold their value. > > Would be cool but won't you need beans anyway for storage, java-based > validations and the like? Sure, but that would be "business beans", not form beans. I've done some reading in the struts documentation, and they made a very clear distinction over there between "business beans" and "form beans". The form beans are just some instance variables with getters/setters for them, but contain no business logic. Once the form is succesfully validated, some action code should then apply the data gathered in the form bean to the business bean. > > I'm not sure if script-based validations are good enough, I prefer to > write the heavy-duty validation stuff in code that is independent from > the web application framework (but that's a personal preference). Sure, I agree with this. The validation I have in mind is mostly things like checking that for number fields, the user entered a number and not some random string (thus checking that the type conversion is succesful), maybe check length of strings, etc. > > > > > ....For those cases where the user just wants to make a form above some > > database-table, EJB or Web-service, we could introduce some > > mapping-concept that allows to map database fields or EJB properties to > > widgets on the forms, so that load and store operations can be done > > without any coding. > > That's where I think a data dictionary can help: forms AND database > fields can be derived from it, it contains more info than just the > forms definitions. > > <snip-other-good-ideas/> > > I don't know the existing XMLForm stuff in as much detail as I'd like > (haven't actually used it yet), so some of my comments might be > irrelevant, but hopefully this helps! Sure helps a lot! -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
