The real problem is the cohesion between Models and Views within the "internal" aspects of web2py. SQLFORM is way too cohesive between validation and rendering. In my opinion, this is why I suggested separate classes, one for the form model, and another for the form rendering(view).
You solution, though works, creates an even bigger mess, since view code would then also, be located in sql.py. -Thadeus On Tue, Dec 15, 2009 at 5:52 PM, Thadeus Burgess <[email protected]> wrote: > I wouldn't be so quick to dismiss as_p as_ul and as_table. As they > offer pre-defined templates. > > Also, I am quickly playing aroudn with your suggestion. I added > .forform() (that just returns self.widget(self, self.default) to field > objects, and I am using FORM. > > The problem with this approach is it still requires the developer to > declare simple things, such as labels and submit buttons... > > The following actually renders perfectly, and validates, however, > requires the developer to define labels, submit buttons and such. > > form = FORM( > FIELDSET(LEGEND("Personal Information"), > P(db.test.first_name.forform()), > P(db.test.last_name.forform()), > ), > FIELDSET(LEGEND("Login Information"), > P(db.test.username.forform()), > P(db.test.password.forform()), > ), > FIELDSET( > INPUT(_type="submit", _value="submit"), > ) > ) > > Is this what you ment by a "generic" solution? > > -Thadeus > > > > > > On Tue, Dec 15, 2009 at 5:22 PM, mdipierro <[email protected]> wrote: >> No. I django's form.as_p, form.as_ul, form.as_table are not an option >> for web2py. Each of them is a specific solution. I think we are >> looking for a general solution instead. >> >> I think this takes two steps: >> >> order 0) SMARTFORM = FORM >> order 1) Fields get an .xml() attributes that serializes them using >> the widget >> order 2) move some of the SQLHTML logic into SMARTFORM >> >> at that point SQLFORM is just an instance of a SMARTFORM (perhaps the >> default SMARTFORM). >> >> On Dec 15, 5:16 pm, Thadeus Burgess <[email protected]> wrote: >>> I still do not see how field sets and legends could be determined by a >>> SMARTFORM using the current way web2py HELPERS work. >>> >>> If you look at ruby on rails, this is why their forms require you to >>> explicitly define your forms. >>> >>> Django has sort of what I would like, however lacks fieldsets. >>> django's form.as_p, form.as_ul, form.as_table, however for more >>> advanced functionality, django forms provide a similar custom >>> interface to the widgets. >>> >>> A perfect form solution would actually be a mixture of both, we could >>> have the same as_p, as_ul, as_table. We could have one class >>> (SmartForm) which just defines the widgets, performs the validation, >>> and sets error messages. This would basically be a class that only >>> provides the same interfaces as SQLFORM.custom. Now with a SmartForm >>> class, you create a (FormRenderer) class that will take a SmartForm as >>> an argument (or SmartForm could take a renderer as an argument), and >>> render the form into HTML. >>> >>> class AsPRenderer(FormRenderer): >>> class AsULRenderer(FormRenderer): >>> class AsTableRenderer(FormRenderer): >>> >>> We're still left with the difficulty of fieldsets. How do we know what >>> fields break up into which fieldsets ? Passing a list that represents >>> the forms structure is the most logical way I can think of doing this >>> (refer tohttp://pastebin.com/m764d7a39for an example... note the >>> matter list) For this there would need to be a class >>> CustomRenderer(FormRenderer) that takes said list as an argument. >>> (again my first question, I do not know how this could be worked with >>> web2py helpers) >>> >>> How does this sound? >>> >>> -Thadeus >>> >>> On Tue, Dec 15, 2009 at 9:09 AM, mdipierro <[email protected]> wrote: >>> > There is no reason to make SQLFORM more complex than it is. Why not >>> > move some of the SQLFORM logic into a new object SMARTFORM(?) and >>> > behaves like FORM but accepts Fields as helpers and processes them >>> > like SQLFORM? parhaps SQLFORM could be derived from such a beast. >>> >>> > Massimo >>> >>> > On Dec 15, 6:06 am, villas <[email protected]> wrote: >>> >> @Thadeus >>> >> Thanks for raising this topic. Tables don't seem correct for laying >>> >> out forms any more. So, should we assume that we're all heading in >>> >> the direction of fieldsets? Surely fieldsets should eventually be the >>> >> default. >>> >>> >> Maybe one way forward to is introduce a new option: >>> >> renderfieldset=False. If true we can get a fieldset and drag our >>> >> forms into the next generation! >>> >>> >> -David >>> >>> > -- >>> >>> > You received this message because you are subscribed to the Google Groups >>> > "web2py-users" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]. >>> > For more options, visit this group >>> > athttp://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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
