[ckan-dev] validation library and deform.

Mon Apr 4 08:19:03 UTC 2011

Hi,

Regarding formencode validators, do you have  examples of validators
we'll need in CKAN which are present in formencode but not colander?
In the past, I've often end up overriding even apparently core
validators (e.g. email regexes, which are often a matter of
interpretation).

Should the fact formencode already has translations be an important
factor?  We're constantly adding new translations strings to CKAN
anyway, and have a pretty active set of translators at work on
Transifex.

Seb

P.S. A minor reason I didn't think formencode would be a good choice
for the framework was that I came across this thread about problems
with i18n; I didn't look into it at the time though, it could've been
user error -- http://groups.google.com/group/pylons-discuss/browse_thread/thread/1b0300ba1a7ed701

On 3 April 2011 23:34, David Raznick <kindly at gmail.com> wrote:
>
>
> On Sun, Apr 3, 2011 at 9:42 PM, Friedrich Lindenberg
> <friedrich.lindenberg at okfn.org> wrote:
>>
>> Hi David,
>>
>> On Sun, Apr 3, 2011 at 1:01 PM, David Raznick <kindly at gmail.com> wrote:
>> > Thanks for the feedback and just the person I wanted to ask something
>> > of.
>> > I am looking into i18n stuff at the moment.
>> > I was hoping to use some built in validators however Colander only has
>> > these
>> > translations.
>> >  https://github.com/Pylons/colander/tree/master/colander/locale
>> > I also can't find a way to pass custom messages or custom "translators"
>> > to
>> > colander.  This worries me as the built in "SchemaNodes" have types
>> > (int,
>> > string) and if these types throw an "Invalid" it can only throw them in
>> > the languages supported.  This means we will have
>> > to effectively subclass
>> > all of colanders "SchemaTypes" and rewrite parts of them.
>>
>> I'm not sure this is true. My guess is that translationstring would
>> check out the kind of well-known locations for l10ns that gettext
>> should use (locale/, LC_MESSAGES/, ...). What speaks against
>> submitting more translations to colander as we go?
>
>
> We could do that.  But we do not know who is going to be using ckan, so our
> users will have to do that.  We could also give translations to formencode
> as we go.
>
>>
>> Passing in custom
>> translators means having to provide validation error messages in the
>> CKAN namespace and I'd really like to avoid that.
>
> I agree with that entirely.  That is why I think formencodes domain is the
> best one as it got the most extensive set of validators/languages already.
>
>>
>> Looking at translationstring this seems to solve a problem I've had
>> with WDMMG where I wanted i18n to run in different domains from the
>> actual "wdmmg" core (i.e. wdmmgext.bergen). This is particularly
>> interesting once you start having plugins that provide their own
>> Genshi templates which need to access another domain. Basically, I
>> ended up writing my own translationstring library at
>>
>> https://bitbucket.org/okfn/wdmmg/src/6603ba8fc04e/wdmmg/config/environment.py#cl-18
>> .
>
>
> Formencode lets you transfer to using its domain really easily.
>
>>
>> > The only library that does this well is formencode (mainly as it by far
>> > the
>> > most mature).  It has
>> >
>> >  https://bitbucket.org/ianb/formencode/src/703c27be52b8/formencode/i18n/ translations.
>> >  Each translation is much more thorough too as formencode has lots of
>> > validators.   My library can easily reuse formencode validators for this
>> > purpose.  You can also pass on your own translator (_, ugettext) if you
>> > like.
>>
>> Would this run in its own domain or in CKANs? If you want to separate
>> domains you necessarily end up with something like my WDMMG hack or
>> translationstring, I think.
>
>
> I have got everything to run through formencodes domain. Apart from our own
> special custom validation errors (which we have made already), which can run
> on ours.
> It seems a shame not to use the most mature sets of validators/translations.
>  Its possible to use formencode validators in colander e.g
>  http://cd34.com/blog/framework/using-formencode-for-validation-with-colander-and-deform/ .
>   However you need to write a wrapper for each.