On 21/03/2006, at 19:41, Michele Cella wrote: > Yes, you're right this could lead to unexpected behaviors, OTOH we > have > an unexpected behavior in both case since the validator of our widget > doesn't respect the one that's being used for validating it. >
It's perfectly expected for me :) What I had in mind was that for simple, one-use widgets use the validator attached to the widget as a default. For other kind of form elements (Passwords) that the validators need to be different in different places I simply don't attach a validator to the widget itself or attach a "fallback" (so can be reused) and change the schema depending on the case (like two kind of users/mailboxes/etc where you require a stronger password in one case) This is one thing I tried hard to get right when implementing generate_schema: Leave the validator in the widget intact as it might be reused. Well, small exception, just change a widget's *own* validator on init time to take into account the subwidgets' validators in the *effective* schema. > What should we do here? is the use case you're describing so common? > should we let people reuse the same widgets over and over for > different > forms in this way? I can't speak for others but I do reuse widgets (I wouldn't even bother to write them if I didn't ;). The problem arises when reusing *instances* of widgets, but, as you can see, this is done every time you use a WidgetsList as the list elements are validator instances. > > We need to solve this, having self.validator != real validator is > something we can't accept IMHO, the only solution I see that can give > us a coherent and predicable behavior without searching for very > difficult solutions is using the metaclass to walk every widget > used by > a compound widget and setting a flag on it (for example _in_use), when > a new compound widget is declared we check this flag and it is True we > issue an error. This would break 70% of my code :( Having an effective/real validator in subwidgets is unavoidable if using schemas which *override* validators. I (ab)use this "feature" frequently to override validators like in the example I posted. I don't see it unacceptable, I'ts just a side effect of using schemas which override widget''s own validators. Everything is normal if no override which is what's normally accepted. I see your problem here when trying to set the is_required flag, but maybe you could make the Form take care of it like it already does for errors as the form *knows* all it's subvalidators *effective* validators when built. This would probably solve it. The bottom line is that containers *should not* modify in any way their child widgets. If this simple rule is kept then instances can be freely reused because they're totally agnostic of their container. Alberto, BTW: Nice job with the Repeating :) haven't tested it yet but looks good.... It seems I can't go offline for more than 3 days without missing a lot... :D --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
