The TurboGears docs show how to assign validators for individual parameters in the validate decorator like this:
@validate(validators={'a':validators.Int(), 'b':validators.DateConverter()})
@error_handler()
def f(self, a, b, tg_errors=None):
# Now a is already an integer and b is already a datetime.date object,
# unless there were some validation errors.
That’s great, but there are some validations that depend on numerous parameters at the same time. For example, you might want to make sure that an employee’s hire date precedes the termination date.
I already knew how to subclass validators.Schema to do this, and then pass that instance into the validate decorator like this:
class MattSchema(validators.Schema):
a = validators.Int()
b = validators.DateConverter()
chained_validators = [blah] # pretend that blah does some compound validation.
@validate(validators=MattSchema())
def f(self, a, b)
This approach is fine, but today I discovered that it is also possible to define a Schema inline, inside the validate decorator, and specify the chained_validators right there, like this:
@expose('.templates.shiftreports.overtime')
@validate(validators=validators.Schema(
a=validators.Int(),
dt=validators.DateConverter(),
chained_validators=[blah]),
state_factory=matt_state_factory)
def f(self, a, b):
What’s the point? Well, it seems wasteful to define a class and hide it in another file if that schema is only going to be used for exactly one controller. Also, this makes it really fast for me to mix and match comound validators with controllers. I don’t need to pop open my separate validators file where all my elaborate schemas live. I can define them right here.
I’m very forgetful too, so I like to keep my code shallow so that I can instantly see what the heck something does. With all the validators right there, I can easily figure out what the system intends to do.
However, I would define a Schema subclass as soon as I see that I need the same thing twice.
I’m happy that the FormEncode authors had the foresight to support this inline approach along with the declarative style.
this is very helpful. I too like to keep my code shallow and Im going to check out FormEncode
thank you matt
was nice article
keep going
Thanks for the post I liked reading it, keep posting interesting stuff like this coming!
Lisa
Some good points raised in that post. Will be back to check for more.
Thanks for explaining by means of giving code..Very useful and good post..I will try this and post my further comments here..
Interesting post. I have made a twitter post about this. Others no doubt will like it like I did.
agence de communication
I think that however, I would define a Schema subclass as soon as I see that I need the same thing twice its very unuseful.
I just wanted to document it so that I wouldn't forget how. Yeah, I
agree that defining things inline is usually not ideal. It isn't easy
to test or reuse the code. There are sometimes moments when it is
useful though. It is nice to see everything all in one place.
agence de communication
Yes Matt It is nice to see everything all in one place 🙂
Declarative style is more appropriate and much easy to understand. Thank you for giving us some insights about schema.
Indeed it is, I like that way as well, that's really the best way.
spam
Thanks for the post.
Very helpful. I found this on google and it fixed my issues.
There are sometimes moments when it is useful though. It is nice to see everything all in one place. However, I would define a Schema subclass as soon as I see that I need the same thing twice.
Thanks
I’m very forgetful too, so I like to keep my code shallow so that I can instantly see what the heck something does. With all the validators right there, I can easily figure out what the system intends to do.
Interesting post. I found this on google. Doesn't really fix what I need though!
Looks a really good post! Feel good to see everything back to it's place! FormEncode authors are doing a really good job!
Cheers!
Thanks for the post.. It really help me a lot..
I'm looking forward for your next post..
I cannot understand how does it work? Can any one help me in figuring this out?
thanks you for sharing a priceless information you have posted. Keep doing this forever. Your article are really 100% beneficent in all ways.
I just wanted to document it so that I wouldn't forget how. Yeah, I
agree that defining things inline is usually not ideal. It isn't easy
to test or reuse the code. There are sometimes moments when it is
useful though. It is nice to see everything all in one place.
I liked your inline validation schema. But I think it might some problem regarding parameters.
Thanks for sharing such a knowledgeable thing with us…..very useful.
I always had problem in executing the inline statements and they were always accompanied with errors..I hope your suggestions might workout..
Yes its right if every thing is in one place so that I can easily figure out what the system intends to do.
Hey I liked your validation schema. Hopefully it will work. Thanks for sharing information.
good observation..
thanks for sharing it..
dentists on brighton
Dentists in Brighton
This article gives the light in which we can observe the reality. this is very nice one and gives in depth information. thanks for this nice article Good post…..Valuable information for all.I will recommend my friends to read this for sure
Thanks
Kane
______________________________________________
british heart foundation diet | cayenne pepper detox | diets for quick weight loss | easy diet plans | maple syrup detox | miracle cabbage soup diet | sugar busters diet | weight gain diets | british heart foundation diet | cayenne pepper detox | diets for quick weight loss | easy diet plans | maple syrup detox | sugar busters diet | weight gain diets | miracle cabbage soup diet
Also, this makes it really fast for me to mix and match comound validators with controllers. I don’t need to pop open my separate validators file where all my elaborate schemas live. I can define them right here.