This does allow for custom form design, as web2py could never know what a
developer "intends" without him/her explicitly declaring it so.
I do think that .as_p, as_table..etc should be considered as a default form
view that could be a one liner call. Massimo you say we need a generic
solution, but we also need specific solutions that give some options but
still do some heavy lifting of the basic form generation.
Think of this, if a separate class for form rendering is created, custom
form rendering classes for any situation would be quite easy, especially if
they interface with an object that has already created say just the
widgets.... it would be exactly like sqlform.custom, but external from the
view. With this, its just a matter of a defining a different renderer for
your app if you need something custom.... Just like how the DAL is being
redesigned to be encapsulation and polymorphism. This is one of those places
that could greatly benefit from polymorphism.
some sample code for idea.
class FormRenderer():
def __init__(form):
...
def __call__():
return TABLE(
for field in self.form.fields:
TR(
TD(LABEL(field.label+":")),
TD(field.widget),
TD(field.comment),
_id = '%s__row'
),
pass
TR(
INPUT(_type="submit", _value="submit"),
),
),
class PRenderer(FormRenderer):
def __init__(form):
...
def __call__():
return FORM(
for field in self.form.fields
P(
LABEL(field.label+":"),
field.widget,
field.comment,
),
-Thadeus
On Tue, Dec 15, 2009 at 6:09 PM, Thadeus Burgess <[email protected]>wrote:
> 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]<web2py%[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]<web2py%[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.
