t+1 - Latest Comments in Sometimes I think validate + formencode is more hassle than it is worth

Re: Sometimes I think validate + formencode is more hassle than it is worth

Jacob — Wed, 29 Oct 2008 22:56:56 -0000

or more concisely (with a behavior that matches your original statement of the problem more closely):

>>> import validino as V
>>> s=V.Schema(dict(b=(V.default(99), V.strip, V.integer())))
>>> s({})
{'b' : 99}

I mostly use formencode nowadays for maintaining and extending code that is already using it. Validino was written quickly and doesn't do everything that formencode does -- it handles messages a bit differently and I'm not sure I like either system much, but an alternative hasn't occurred to me. Also it doesn't handle schema introspection particularly well, which is something you'd want in some cases. But you've found what I like about the approach -- that it is entirely transparent what the meaning of a particular validator is, because you build up the various parts of it via function composition.

Re: Sometimes I think validate + formencode is more hassle than it is worth

Matt Wilson — Wed, 29 Oct 2008 10:27:08 -0000

Yeah, a lot of problems could be solved with a lot of example formencode recipes, especially the weird stuff. I'm going to write up a few of my recipes and see if anyone else wants to help.

It's a great library, but it's just not that easy for me to jump in, build a complex validator, then walk away from formencode for a month.

Re: Sometimes I think validate + formencode is more hassle than it is worth

Felix Schwarz — Wed, 29 Oct 2008 03:18:01 -0000

I think what most people find confusing is for FormEncode 'parameter missing' and 'parameter empty' are two different cases. There is no 'default' but only if_missing and if_empty. Furthermore you can define what you consider an 'empty' value.

Then FormEncode has some brain-dead parameter names like 'not_empty'. What the hell? I mean negative logic is hard to grasp. Instead of calling it 'required'.

Another grip I have with FormEncode is that there are almost no unit tests and most validators rely on the input values being strings which is plain wrong if you use FormEncode's variabledecode.

But some things in FormEncode are really nice like the declarative object or schema inheritance. One of my imagined projects (though low priority at the moment) is to build my own validator library on the basis of declarative which hopefully avoid the common FormEncode pitfalls.

Re: Sometimes I think validate + formencode is more hassle than it is worth

Matt Wilson — Tue, 28 Oct 2008 23:57:58 -0000

OK, after all of 5 minutes, I figured out to use the compose + default + to_list to make sure I got a default value.

import validino
d = dict(a=1, c=3) # this will be my input data
f = validino.compose(validino.default(99), validino.to_list())
v = dict.fromkeys('abc', f)
s = validino.Schema(v)
print s(d)

So, when do you revert to formencode? What does formencode offer that this approach doesn't, or couldn't?

Re: Sometimes I think validate + formencode is more hassle than it is worth

Matt Wilson — Tue, 28 Oct 2008 23:20:44 -0000

Hi Jacob -- that validino package looks neat. How would I do something like stick in a value for a key if that key is not defined in the initial data passed into the schema?

For example, if my data is d = dict(a=1, c=3), then I want my schema to create a key b that points to, say, 99. How to?

Re: Sometimes I think validate + formencode is more hassle than it is worth

Jacob — Tue, 28 Oct 2008 20:03:17 -0000

I had a similar reaction to formencode. Every time I've picked it up to use, I've run into edge cases and surprises, especially about inheritance. And these problems had nothing to do with the problem space that I wanted to think about, and everything to do with implementation details of the library. Now, Ian is a great programmer, so I'm not knocking the quality of the implementation at all -- but in my view the declarative syntax of formencode, while appealing for simple cases, doesn't scale well. So I wrote a library for my own use ("validino") that I tend to use (I still use formencode sometimes). Validino's behavior is always transparent, although it has its own limitations and I don't make claims for it -- it's a minor effort. What I'd really like to see is a well-thought out, next-gen formencode that stands on formencode's shoulders, but reduces or eliminates the DSL tax so you can use it without needing to think much about the library and its quirks. That's why we use Python and not Perl, right?

Re: Sometimes I think validate + formencode is more hassle than it is worth

Matt Wilson — Tue, 28 Oct 2008 16:39:30 -0000

Hi Mike, thanks for the comments.

Maybe I'll put together some restructured text documentation of all
the formencode tricks that I know of and then see if anyone else wants
to add their stuff to the pile.

Matt

Re: Sometimes I think validate + formencode is more hassle than it is worth

mike bayer — Tue, 28 Oct 2008 16:21:47 -0000

The "None" thing is one of maybe a few very glaring issues which should be changed. If you look at the source code, the Schema object totally bypasses the validator if the value is None. This is an inconsistency in how the data is handled and it would be nice if Schema/FancyValidator had one single datapath for all values.

Its also confusing to have to integrate composite form elements with variabledecode and it would be nicer for this to be more explicitly integrated.

Beyond that I think the docs just need more real world examples.