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 <mdipie...@cs.depaul.edu> 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 <thade...@thadeusb.com> 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 <mdipie...@cs.depaul.edu> 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 <villa...@gmail.com> 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 web...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > web2py+unsubscr...@googlegroups.com.
>> > 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 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.
>
>
>
--
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.
