Alberto Valverde wrote:
> Ok, refactored meta stuff to widgets.meta. I had to add a compound
> attr to Widgets so meta can know when a field is compound without
> circular imports.
>

See below...

> On 10/03/2006, at 19:40, Michele Cella wrote:
>
> That was not exactly the question I wanted to make, sorry. What I
> meant is that unpacked_error dicts have a key for compound widgets
> too when they have an error. I think it contains a list of all errors
> for all inner widgets, this is just how FE works. I noticed this on
> the browser test so cannot say for sure what format it's in (has
> __str__ for sure :) You can try to reproduce it by commenting those
> two lines beneath the comment (sic). Right now they are ignored.
>

I'm not quite tuned on this thing will take a look when I have time...
:D

> >
> > I think that without ignore_key_missing = True disabled_fields will
> > not
> > work right, am I wrong? this wil also fix #659 I guess... not sure.
>
> Mmmm, I'm not sure but I think they will not :( However, I think we
> can add it back safely as ignoring missing keys shouldn't be as
> dangerous as accepting spurious keys. Anyway, I think that maybe we
> shouldn't add because you can always override that behavior by
> passing a custom schema to forms which you expect to disable some
> fields.
>

Isn't disabled_fields intended to be used at display time? for example
to redisplay a form without some fields? in that case the validator is
already ready, so I guess we need the ignore_missing can you give it a
shot while committing? I'm pretty sure it will fix also Jason bug.

> What I'd really like to fix when this get's in (I have a sort of
> cumbersome poor-man's svn with this patch numbering stuff :) Is the
> allow_extra_fields = True (setting it to false) and possibly adding a
> filter_extra_fields=True too. Needs some more testing though as some
> tests where failing when I tried it (probably because some input-
> expecting widget's didn't have a validator) but didn't look into it
> too closely... There's a post in this thread where I explain better
> the reasoning behind this...
>

We may ask Kevin what's opinion, should we expect a validator for every
field?

> My goal here is too make the default Schema @ validators as strict as
> possible (secure by default) but with the possibility of loosening it
> up by subclassing.
>

That's a good goal. ;-)

> Well, I'm ready to commit :) , comments on validation9.patch @ #613?
>

Yep, :P

- why return getattr(widget, 'full_qualified_form', True)  shouldn't
this be False for default? just wondering...

- can we remove compound from the base widget class? and instead use
getattr(widget, "compound", False)? it was there before but I've
removed it since it semmed silly from a parent point of view... :D

Other than that, wonderful work.

Ciao
Michele


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" 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/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---

Reply via email to