Michele, Thanks for a nice reply.
I think differences are mostly come from our personal preferences; I think I'd be just as happy with the solution you propose. > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] > On Behalf Of Michele Cella > Sent: Sunday, April 09, 2006 12:11 PM > To: TurboGears Trunk > Subject: [tg-trunk] Re: broken FileField widget? > > > > > > Sure. > > > > One thing. If I'm not mistaken there is no standard way in validator's API > > to check > "not_emptiness" except trying to validate an empty string, which is kinda > broken (e.g. > validators.String(not_empty=False, if_invalid='abc')). > > > > And I argue that TextField may need to know whether it is required or not > > regardless of > validator. For instance, to display itself differently. And if you agree with > that and agree that > querying validator about it not an option then adding "is_required" is the > only way to go. > > > > Hi Max, > > The TextField already applies a "requiredfield" class to itself if is > required by the validator and personally I wouldn't trust anything > other than that for doing this thing since you can define a validator > in the schema that's required and at the same time having > is_required=False on your field, that's another point why I think this > is the wrong solution. > > IMHO it's pretty safe to check for is_required by validating with an > empty string because that's the only empty "signal" you can get from > the web where everything is just a string. > > Your example: > > >>> test = validators.String(not_empty=True, if_invalid="abc") > >>> test.to_python('') > 'abc' > >>> > > No exception raised, this is a FE problem, but personally I can't see > the usefulness of if_invalid since you're saying "validate this, if > invalid the value is this", then why validating at all? > > > Now the question is how to "combine" is_required with validator. A couple > > of variants has > been proposed, here is one more: chain user-supplied validator with > NotEmpty() validator if > is_required==True. > > > > That's what I've been already doing in my fist patch, it's a big hack > since the use has no control over the final resulting validator that's > wrapped *magically* inside a Any/All validator along with > Empty/NotEmpty, that's why I've decided to fix the problem inside FE > itself. > > > Another option is not to combine them at all. Attribute "is_required" > > related to view and let > it be separate from whatever validation method is used. This arguably breaks > DRY as you > would have to write TextField(is_required=True, > validator=Int(not_empty=True)) but OTOH > explicit is better than implicit. > > Why should is_required be related to the view? the problem is that we > are looking at is_required as a thing unrelated to the the validation > aspect, that's not the case. > > If you need is_required just for the css class (that as I said is > already there automatically) you do: > > css_classes = ["required"] > > Having is_required separated from the validator doesn't make sense > since the whole point of this discussion is tweaking this parameter of > the validator. > > Only the validator can define if a field is required or not since is > the one validating its input I can't see how this is not explicit, > having two ways of doing this thing is plain wrong IMHO. > > "There should be one-- and preferably only one --obvious way to do > it." > > So what is the obvious way? > - using the validator parameter and not_empty > - using is_required > - what's the relationship between is_required and the validator? why > they are separated? > > With the last solution you have only this way: > > 1) a new validator > TextField(validator=Int(not_empty=True)) > > 2) tweak the default validator > TextField(validator_args=dict(not_empty=True)) > > no conflicts, at init if validator is not None validators_args is not > considered, anyway no one will use validator and validator_args (better > name please) at the same time since it's obvious the use case they > cover, "obvious way to do it". > > with the first one: > > 1a) a new validator > TextField(validator=Int(), is_required=True) > > 1b) a new validator (with is_required=False by default O_o) > TextField(validator=Int(not_empty=True)) > > 1c) no validator > TextField(is_required=True) > > 2) tweak the default validator > TextField(is_required=True) > > ... > > > > > Above you wrote that you didn't want to hide fE and here you're proposing > > widget to > provide default validator. > > validator -> brand new FE validador > validator_args -> arguments for the default *FE* validator provided by > the widget > > Anyway isn't this the whole source of our discussion? providing a > default validator for the FileField and having (as requested by Kevin) > an easy way of marking it as required without redefining the whole > validator? > > If we don't want to provide any default validator you just need (as > Alberto said and also me on my first reply) this: > > TextField(validator=Int(not_empty=True)) > > The only point against the last solution I can see is that is more > typing but I think is more pythonic, explicit and doesn't leave space > for ambiguity since it's clear what the relationship between validator > and validator_args is, and that you need to use FE to do these things. > > Thanks again! ;-) > > Ciao > Michele > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.4.0/305 - Release Date: 08.04.2006 > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
