I do not think this is about decoupling the presentation logic from the... tree structure.. I am saying that validation and presentation should be decoupled. A Form should be able to validate without needed to know what it tree looks like. All the form validation should care about is what the data is supposed to be, and convert request.vars into this. If you separate the validation, creating the necessary presentation or tree structure is really just one more step. The problem I am concerned with is that FORM is both "Structure" and "Validation". The presentation (the tree) should not be concerned with validating the data, only with displaying the said data.
There are of course forms other than html forms. A client based software that uses json to post data is a type of "form", although not created with html, the concept is the same, there is a data set, that represents some object, that needs to be validated, regardless of the presentation of this data. In all honestly this is an issue that has to do more with software standards and maintenance than anything else. Think of the advantages we would gain if there was a separation between the data and the presentation (which web2py does a great job at in other areas as it is, new dal is sweet). One class would hold the "logic" of the form, it handles the data, performs validation on incoming post vars, parses the data to the correct python types. Then another class, takes this data, and creates the structure, the html form that represents it. With this, forms don't necessarily need a structure or view to validate themselves, and presentations come from a parsed data set. In fact, what would make more sense is the separation into a FormModel, and a FormView. -Thadeus On Sun, Dec 20, 2009 at 11:22 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > helpers correspond to tags and they are represented as trees. The root > of the tree is the tag itself and the children are the tags contained > within. The FORM helper has a special accept method that performs the > tree traversal and finds all nodes which are INPUT, TEXTAREA or SELECT > and process them. > > SQLFORM just builds a particular tree structure. > > FORM lets you build any tree structure you want. > > You can already create and store subtrees (like a fieldset) and insert > them into an existing FORM/SQLFORM. The problem is naming conflicts. > > I see different needs from your emails, and correct me if I am wrong. > > 1) FORM currently does not understand Field objects and their widgets. > SQLFORM does. Perhaps FORM should thread Field objects as special > helpers themselves. So you can insert Fields directly in the tree > structure of a FORM, not just a SQLFORM. This is not easy but can be > done. Yet, this would go in the direction of adding presentation logic > into the controller. Not what users normally like. > > 2) Have custom forms that contains multiple instances of the same > field. There cannot be two INPUT fields in the tree with the same > name. This is a HTML constraint and by-passing it would require that > field names in form no longer correspond to variable names in web2py. > Perhaps there should be a way to rename fields when inserted in the > tree? > > 3) Decouple completely the logic content of a form (the set of leaves > that are INPUT fields) from their representation (the tree structure). > Are there forms other than HTML forms? No. That is why they are > coupled. Decoupling means a INPUT field no longer knows its place in > the page and this may be a a problem when displaying errors for > example. It would also cause the FORM object to be a new kind of > animal from regular helpers. Anyway. It can be done bt it would > require the introduction of a new type of form object that is an > alternative and not compatible with the current one. It seems to me > this decoupling is not related and would not address any of the issues > 1) and 2), and it would only make lots of stuff more complex that > needs to be. > > Massimo > > -- > > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To post to this group, send email to web...@googlegroups.com. > To unsubscribe from this group, send email to > web2py+unsubscr...@googlegroups.com<web2py%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/web2py?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
