fieldsets? how to declare them?
Jorge Vargas
errors. with the different syntaxes I have tried.
I want to build a form that has two fieldsets to add some fancy CSS
around their borders. but I'm just stuck should I make a class that
extends *ListForm, which has a class named fields and inside the
FieldList? I have search the group and the examples and I see no use
of this Widget.
almost all variables of nested classes I have try yield.
Module tw.forms.fields:254 in update_params
<< def update_params(self, d):
super(Form, self).update_params(d)
d['value']['submit'] = d['submit_text']
d.method = d.method.lower()
# Fails W3C validation if present
>> d['value']['submit'] = d['submit_text']
<type 'exceptions.TypeError'>: 'NoneType' object does not support item
assignment
Jorge Vargas
> Hi I have been trying to get this working but I'm getting some weird
> errors. with the different syntaxes I have tried.
>
> I want to build a form that has two fieldsets to add some fancy CSS
> around their borders. but I'm just stuck should I make a class that
> extends *ListForm, which has a class named fields and inside the
> FieldList? I have search the group and the examples and I see no use
> of this Widget.
ok I found a way inspired by this tutorial
http://wiki.pylonshq.com/display/pylonscookbook/Custom+ToscaWidgets+Forms
class FirstFieldSet(ListFieldSet):
class fields(WidgetsList):
foo = For()
class SecondFieldSet(ListFieldSet):
class fields(WidgetsList):
bar = Bar()
class MyForm(ListForm):
class fields(WidgetsList):
firstFieldSet = FirstFieldSet()
secondFieldSet = SecondFieldSet()
is this the "correct" way?
Alberto
On Apr 22, 12:03 am, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
> > Hi I have been trying to get this working but I'm getting some weird
> > errors. with the different syntaxes I have tried.
>
> > I want to build a form that has two fieldsets to add some fancy CSS
> > around their borders. but I'm just stuck should I make a class that
> > extends *ListForm, which has a class named fields and inside the
> > FieldList? I have search the group and the examples and I see no use
> > of this Widget.
>
> class FirstFieldSet(ListFieldSet):
> class fields(WidgetsList):
> foo = For()
>
> class SecondFieldSet(ListFieldSet):
> class fields(WidgetsList):
> bar = Bar()
>
> class MyForm(ListForm):
> class fields(WidgetsList):
> firstFieldSet = FirstFieldSet()
> secondFieldSet = SecondFieldSet()
>
> is this the "correct" way?
widget for that matter) by passing a normal list (a là TG widgets) if
this syntax looks better to you:
FieldSet("foo_fs", fields=[....])
Alberto
Jorge Vargas
form is more appropriate. But I'm having mix feelings about this,
adding the extra widget is generating a lot of undesired side effects.
to start the validator code is much more complex as now I have a dict
of dicts in form_result, where the fieldset is basically an eye candy
feature which shouldn't polute beyond it's mare representation. So now
I'm thinking if I should make a custom widget that will have the
fieldset only on the template to eliminate the extra widget object and
the complexity of form_result, and beyond.
>
> Alberto
> >
>
Paul Johnston
adding the extra widget is generating a lot of undesired side effects.
to start the validator code is much more complex as now I have a dict
of dicts in form_result, where the fieldset is basically an eye candy
class StripSubDict(fe.Schema):
def _to_python(self, value, state):
return super(StripSubDict, self)._to_python(value, state).get('mysubdict', {})
I do have an idea for some changes to TW to fix this up properly. Not a priority for me at the mo, but do create a ticket, so we don't forget about this.
Paul
Alberto Valverde
>(...)
> given that the list is pretty big for this cause it seems the first
> form is more appropriate. But I'm having mix feelings about this,
> adding the extra widget is generating a lot of undesired side effects.
> to start the validator code is much more complex as now I have a dict
> of dicts in form_result, where the fieldset is basically an eye candy
> feature which shouldn't polute beyond it's mare representation. So now
> I'm thinking if I should make a custom widget that will have the
> fieldset only on the template to eliminate the extra widget object and
> the complexity of form_result, and beyond.
This is by design. Nested widgets are handled like this to mirror the
nested structure of the objects they're generating views for and, in the
case of InputWidgets, provide a nested structure after validation which
can be easily used to update the objects.
The easiest way, IMO, to handle this would be at the template (to separate
layout logic from validation code etc..). From memory, I once implemented
something to make this generic (so I don't have to override lots of
templates just to group fields in fieldsets) with something like this:
class FormWithFieldSets(Form):
params = ["groups"]
groups = [
('Personal info', ('name', 'age',)),
("Contact info", ('phone', 'address'))
]
class fields(...):
name = TextField(...)
age = TextField()
phone = TextField(...)
address = TextField()
And then a template something like this:
<form ...>
<fieldset py:for="legend, field_names in groups">
<legend py:content="legend" />
<input py:for="fname in field_names" py:replace="display_child(fname)" />
</fieldset>
</form>
(refactoring needed to create a reusable base widget is left as an
exercise to the reader ;)
Perhaps a "nested=False" flag that child compound widgets could have to
signal their parent not to perform this wrapping could be implemented
though I'm not sure if it's feasible without complicating the code too
much.
Alberto
Jorge Vargas
get the best of both worlds, but I wasn't sure if it was the best
approach.
>
> (refactoring needed to create a reusable base widget is left as an
> exercise to the reader ;)
>
> Perhaps a "nested=False" flag that child compound widgets could have to
> signal their parent not to perform this wrapping could be implemented
> though I'm not sure if it's feasible without complicating the code too
> much.
that was my second thought, but now I must sleep I'll look into it
tomorrow, but I think it's an obscure feature. that you won't use
unless this bites you.
>
>
>
> Alberto
>
>
> >
>