formencode-discuss Mailing List for FormEncode for Python (Page 29)

There's been a whole bunch of activity lately in form generation 
libraries, especially around FormEncode and SQLObject.  There's a bunch 
of options out there, and I haven't had a chance to look at them all 
(actually any of them yet ;), and I'm not even sure what all there is.

It would be really helpful to make a roundup of these, to get an idea of 
where we are.  I'm interested both in ones that are embedded in other 
libraries or apps (if they could be extracted), and stand-alone 
libraries.  So I'd really appreciate it if people could put together a 
little summary (or copy one they've already written).  Please include:

* The name and URL of the package and/or repositories
* If it is embedded in another project, where in the project to look 
(i.e., the module name(s))
* Any URLs of examples or docs

Some additional commentary would also be helpful, like:

* What are your design goals?
* Does it have any novel features you'd like to point out?
* How does it deal with exceptional cases, and developer/designer 
tweaking of forms?
* Does it have any fancy widgets (e.g., Javascript)?
* Presumably it uses FormEncode; to what degree?  Does it use htmlfill? 
  Does it integrate specifically with the validation in any way?
* Thoughts on the future?  Is this a prototype or a serious library? 
Are you looking to merge it with something else?
* Any special SQLObject integration?  Extensible integration?  General 
CRUDiness?

Not everyone is necessary subscribed to all these lists, but if you are 
involved in these things I would encourage you to be at least subscribed 
to formencode-discuss 
(http://lists.sourceforge.net/lists/listinfo/formencode-discuss).  You 
can also subscribe to google groups and disable email delivery.  Sadly 
GG breaks mailing list conventions with its stupid reply-tos, so 
reply-to-all on this message may not pick up all these lists.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

I've been working on a form generation toolkit that integrates well with
FormEncode... its still under heavy development, of course, but I've seen a
lot of discussion of this topic on various mailing lists over the past few
days, and so wanted to get something out. Release early and all that. So yo=
u
can get it from

https://developer.berlios.de/project/showfiles.php?group_id=3D4967

There's a README with a tutorial in there, which is also provided as a
friendlier README.html. It requires FormEncode (I developed with FormEncode
0.22, but I expect it will work with older versions). Current features
include default values, intelligent detection and rendering of "required"
fields, extensive facilities for customization of the output markup, etc.
Mainly, I've tried to make it easy to use.

I'm a Cherrypy guy, and so aimed it at use with that; it should be perfectl=
y
usable with TurboGears too (although its largely orthagonal to the
(problematic) way that TurboGears currently encourages you to use forms).
Really, its usable with any framework that lets you access form submissions
as a python dict.

For a really quick intro, I've pasted the contents of a sample script that
uses formulaic below, along with the output that script would produce. The
html this script produces isn't very realistic, but customization of the
markup is very easy (I'd call it my top design goal). I didn't demonstrate
it simply to keep the script short.

Its nowhere remotely near finished, of course, but hopefully is at a a poin=
t
that it can be useful for real world work. Questions, suggestions, etc. are
extraordinarily welcome.

Greg

example.py
-------------
#!/usr/bin/python

from formencode import validators
from formencode.api import Invalid

from formulaic import forms
from formulaic import basicwidgets as widgets

form =3D forms.RequirementsForm()
form.attrs['id'] =3D 'myform'

form['age'] =3D widgets.TextInput(validators.Int(), 'Age')
form['age'].attrs =3D {'size':'4', 'maxlength':'3'}

colors =3D ['Red', 'Green', 'Blue']
form['favcolor'] =3D widgets.Select(validators.OneOf(colors), 'Favorite
color', options=3Dcolors)

form['pie'] =3D widgets.CheckboxInput(validators.Bool(), 'I like pie')

inputs =3D {'age':'ten', 'favcolor':'Green', 'pie':'checked'}

try:
data =3D form.schema.to_python(inputs)
print data
except Invalid, error:
print form.render(inputs, error.error_dict)

-----------------

output:

<form action=3D"" method=3D"POST" id=3D"myform">

<label class=3D"required">Age</label>
<input type=3D"text" name=3D"age" value=3D"ten"/>
<span class=3D"error">Please enter an integer value</span>

<label class=3D"required">Favorite color</label>
<select type=3D"text" name=3D"favcolor">
<option value=3D"Red">Red</option>
<option selected=3D"selected" value=3D"Green">Green</option>
<option value=3D"Blue">Blue</option>
</select>

<label>I like pie</label>
<input type=3D"text" checked=3D"checked" name=3D"pie"/>

<input type=3D"submit" value=3D"Submit"/>

</form>

Indeed; applied in r1132

Alexey Shamrin wrote:
> Hello!
> 
> validators.StringBoolean doesn't work with unicode. For details see
> http://groups.google.com/group/turbogears/browse_frm/thread/89f54a2eb5e16d14
> 
> Here is the patch:
> 
> --- validators.py.original      Thu Oct 20 04:29:48 2005
> +++ validators.py       Thu Oct 20 04:31:08 2005
> @@ -1516,7 +1516,7 @@
>      messages = { "string" : "Value should be %(true)r or %(false)r" }
> 
>      def _to_python(self, value, state):
> -        if isinstance(value, str):
> +        if isinstance(value, basestring):
>              value = value.strip().lower()
>              if value in self.true_values:
>                  return True

Hello!

validators.StringBoolean doesn't work with unicode. For details see
http://groups.google.com/group/turbogears/browse_frm/thread/89f54a2eb5e16d1=
4

Here is the patch:

--- validators.py.original      Thu Oct 20 04:29:48 2005
+++ validators.py       Thu Oct 20 04:31:08 2005
@@ -1516,7 +1516,7 @@
     messages =3D { "string" : "Value should be %(true)r or %(false)r" }

     def _to_python(self, value, state):
-        if isinstance(value, str):
+        if isinstance(value, basestring):
             value =3D value.strip().lower()
             if value in self.true_values:
                 return True

--
Alexey

On Oct 12, 2005, at 4:22 PM, Ian Bicking wrote:

>
> I wanted to get this out before I go out on vacation, since I think  
> it's useful in the context of some of the form discussions that  
> have been going around on these lists.  It's a Javascript library  
> (using MochiKit) that primarily implements the repeating field  
> model as defined in WHAT-WG: http://www.whatwg.org/specs/web-forms/ 
> current-work/#repeatingFormControls
>
> The library is located at:
>   http://svn.colorstudy.com/home/ianb/form.js
>
> This is just a temporary location.

I started taking a look at this... but do you have any HTML that  
demonstrates any of this working?  That'd certainly save time.

-bob

I wanted to get this out before I go out on vacation, since I think it's 
useful in the context of some of the form discussions that have been 
going around on these lists.  It's a Javascript library (using MochiKit) 
that primarily implements the repeating field model as defined in 
WHAT-WG: 
http://www.whatwg.org/specs/web-forms/current-work/#repeatingFormControls

The library is located at:
   http://svn.colorstudy.com/home/ianb/form.js

This is just a temporary location.

Ultimately I'd like to contribute it to MochiKit (MochiKit.Forms?), but 
I won't have the time to do the necessary work on it for a while -- it 
needs tests, there's some features that should be converted to be more 
like what WHAT-WG defines (at least to the degree this overlaps with 
those specs), and of course documentation.

One of the advantages of this model is that it is largely declarative -- 
the Javascript works on well-defined extensions to HTML, and you can 
write useful templates that use this functionality without writing any 
Javascript, and without any (clever and dangerous) Javascript code 
generation.  It also happens to fit in nicely with some features of 
FormEncode (ForEach).  Generally speaking, the Web Forms 2.0 spec 
defines most of what is necessary to do form validation, both Ajaxy and 
Boring Old Client-Side-Only Javascript.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

I've added some experimental form generation code.  It arose out of some
initial experiments with PEAK's generic functions; to install those:

  easy_install -Zf http://peak.telecommunity.com/snapshots/ RuleDispatch

Anyway, the experiment is in formencode.formgen, formencode.sqlformgen
(the generator for SQLObject) and tests/test_makeform.py

The "context" is really vague to me at this point.  In part it's there
to make specialization in applications easier, like you do:

  class AppContext(Context):
      pass

  form, schema = makeform(obj, AppContext(screen='add'))

And then specialize with:

  @makeform.when('isinstance(obj, StringCol) and isinstance(context,
AppContext) and context.screen=="add"')
  def makeform_custom(obj, context, next_method):
      field, schema = next_method(obj, context)
      field.width = '100%'
      return field, schema

Or something like that, I dunno.

The other part I haven't figured out (the failing test) is how defaults
get in there.  I think the (form, schema) return value should turn into
an object (called what?) that also holds defaults.  But I dunno yet.

  Ian

Shannon -jj Behrens wrote:
> Does it make more sense now?  The most important thing I'm saying is
> that if I were in your shoes I wouldn't distribute translation
> catalogs with FormEncode.  Let the users of your library translate
> those strings alone with the rest of their application.
> 

I think we should provide both possibilites. Standalone FormEncode 
specific mo files and application specific mo files.
The domain and directory of the mo files should be attributes of the 
state object along with the locale attribute.
So the user has the ability to set his own mo files. We should also 
distribute the po files, so the integration of the messages in the 
applications po file can be done by copy and paste.

--
Greg

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> Both these are applied now, plus there is a validate_python setting
> which, if set to False, will let otherwise Invalid-seeming values get
> through (which is usually what I find I want, since I can't give errors
> to the client about data they don't yet have access to).

Sounds like a good addition, and I agree that it makes sense as a
default. Generally, the Python side will know what it's doing...

Kevin

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> Kevin Dangoor wrote:
> > Because of the if_empty parameter, the StringBoolean validator in svn
> > was returning False (not 'false') for from_python(False). This change
> > fixes that:
>
> I wonder if 0/False should really be considered "empty"?  I.e., maybe
> those values should be special-cased not to be empty.

I don't think of those as empty. "Empty" implies a void. "", [], (),
None are all empty. 0 and False are actual values.

> I think so.  But also if_empty applied to from_python seems a little
> fishy as well.  I suspect it should not be at all.  I also suspect that
> FancyValidator.attempt_convert is not a very helpful abstraction.

I agree that if_empty does seem a little fishy applied to from_python.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Kevin Dangoor wrote:
> On 10/5/05, Ian Bicking <ia...@co...> wrote:
> 
>>Kevin Dangoor wrote:
>>
>>>Because of the if_empty parameter, the StringBoolean validator in svn
>>>was returning False (not 'false') for from_python(False). This change
>>>fixes that:
>>
>>I wonder if 0/False should really be considered "empty"?  I.e., maybe
>>those values should be special-cased not to be empty.
> 
> 
> I don't think of those as empty. "Empty" implies a void. "", [], (),
> None are all empty. 0 and False are actual values.
> 
> 
>>I think so.  But also if_empty applied to from_python seems a little
>>fishy as well.  I suspect it should not be at all.  I also suspect that
>>FancyValidator.attempt_convert is not a very helpful abstraction.
> 
> 
> I agree that if_empty does seem a little fishy applied to from_python.

Both these are applied now, plus there is a validate_python setting 
which, if set to False, will let otherwise Invalid-seeming values get 
through (which is usually what I find I want, since I can't give errors 
to the client about data they don't yet have access to).

Hmm... I wonder if validate_python should be False by default. 
Conversions are still applied regardless.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Kevin Dangoor wrote:
> Because of the if_empty parameter, the StringBoolean validator in svn
> was returning False (not 'false') for from_python(False). This change
> fixes that:

I wonder if 0/False should really be considered "empty"?  I.e., maybe 
those values should be special-cased not to be empty.

I think so.  But also if_empty applied to from_python seems a little 
fishy as well.  I suspect it should not be at all.  I also suspect that 
FancyValidator.attempt_convert is not a very helpful abstraction.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Would you like to develop this in a branch?  I don't think it should go=20
in the trunk to start out with.  Anyway, I can set you up with commit=20
access; if you generate a line with htpasswd I'll add you.  I won't=20
branch it now, but when you are ready to do work you can branch with:

svn cp http://svn.colorstudy.com/FormEncode/trunk=20
http://svn.colorstudy.com/FormEncode/branches/gettext-enabled

Gregor Horvath wrote:
>=20
> Ian Bicking schrieb:
>=20
>> I don't really know the best way to do internationalization.  But I=20
>> had intended it to be possible in some fashion -- probably with the=20
>> logic somewhere in the formencode.api.Validator.message method.  The=20
>> locale could be passed in attached to the state in some fashion (or in=
=20
>> a threadlocal global or somesuch), and could translate the message=20
>> before doing the substitutions.  The other part then would be=20
>> extracting the messages so they can be translated.
>=20
>=20
> for the messages there is gettext
>=20
> http://docs.python.org/lib/node333.html
>=20
>>
>> But I've never done anything with internationalization, so I'm very=20
>> open to advise.  For locale-related validators like date and zip code,=
=20
>> I think in some cases there should be locale-dependent versions (e.g.,=
=20
>> for postal codes), and in some cases we can add the necessary logic=20
>> (e.g., in the date converter).  Right now there's some configurability=
=20
>> to the date converter (month_style), but it's limited, and if the=20
>> locale is attached to the state then you could support more than one=20
>> format at a time.
>>
>=20
> So the solution would be:
>=20
> 1. Use gettext for the messages (seems that there is only litte change=20
> to the current code required)
>=20
> 2. locale dependend validation logic with slightly different semantics=20
> (e.g date) should be included in the current classes of validators.py
>=20
> 3. Local specialities schould be provided by seperate specialized=20
> classes. (e.g postal codes, telephone numbers, StateProvince)
>=20
> 4. The language, locale setting used should be controlled by an to be=20
> defined state attribute (1 & 2, 3 is a different class that has to be=20
> explicitly called by the user). If it is omitted the systems standard=20
> locale is used. I cannot say where is the best place for that attribute=
=20
> because I do not know the code of formencode that much.
>=20
> If I find the time I=B4ll start changing validators.py to support gette=
xt=20
> and create the german message file. OK?
>=20
> --=20
> Greg


--=20
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Shannon -jj Behrens wrote:
> I had to support this in FormValid, Aquarium's form validation library
> (long story).  Here are some things to keep in mind when doing this in
> FormEncode:
> 
> o It's helpful to let the programmers easily pass in their own error
> messages.  That way they're in complete control of these sticky
> situations.

This is already handled, e.g., DateConverter(messages={'after': "I find 
it implausible you are more than 100 years old"}, 
earliest_date=datetime(1905, 1, 1)).

> o Remember that you can't use a global translation instance. 
> Eventually, you'll need to support more than one language at the same
> time.  In Aquarium, I handled this by attaching the translation
> instance to the context.  Each page request has its own context. 
> Hence, multiple users can use multiple languages at the same time.

You could use a threadlocal object to manage the locale, assuming a 
single request is handled solely by one locale, i.e., a single thread 
uses only one locale at a time.  Unless you are using single-process 
non-threaded serving like Nevow or somesuch.

But anyway, the state object can be passed into a validation, and 
arbitrary attributes can be attached to it.  So I'm guessing the locale 
should be determined with:

   locale = getattr(state, 'locale', None)

> o I personally would not want the FormEncode strings to have their own
> separate gettext domain.  Rather, I would scan FormEncode for
> translatable strings (using gettext, of course) and translate those
> alongside all my other application's strings.

Well, that's terminology I don't understand ;)  Does scanning produce 
.po files?  Can those be merged and extracted?

Eh, I don't know much about this stuff at all.

> o Consider passing in a translation instance to FormEncode.  You can
> use the NullTranslation as the default.

If that's more convenient, then it could be done with:

   translator = getattr(state, 'translator', NullTranslation)

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

I had to support this in FormValid, Aquarium's form validation library
(long story).  Here are some things to keep in mind when doing this in
FormEncode:

o It's helpful to let the programmers easily pass in their own error
messages.  That way they're in complete control of these sticky
situations.

o Remember that you can't use a global translation instance.=20
Eventually, you'll need to support more than one language at the same
time.  In Aquarium, I handled this by attaching the translation
instance to the context.  Each page request has its own context.=20
Hence, multiple users can use multiple languages at the same time.

o I personally would not want the FormEncode strings to have their own
separate gettext domain.  Rather, I would scan FormEncode for
translatable strings (using gettext, of course) and translate those
alongside all my other application's strings.

o Consider passing in a translation instance to FormEncode.  You can
use the NullTranslation as the default.

I hope that helps.

-jj

On 10/5/05, Gregor Horvath <g.h...@gm...> wrote:
>
> Ian Bicking schrieb:
>
> > I don't really know the best way to do internationalization.  But I had
> > intended it to be possible in some fashion -- probably with the logic
> > somewhere in the formencode.api.Validator.message method.  The locale
> > could be passed in attached to the state in some fashion (or in a
> > threadlocal global or somesuch), and could translate the message before
> > doing the substitutions.  The other part then would be extracting the
> > messages so they can be translated.
>
> for the messages there is gettext
>
> http://docs.python.org/lib/node333.html
>
> >
> > But I've never done anything with internationalization, so I'm very ope=
n
> > to advise.  For locale-related validators like date and zip code, I
> > think in some cases there should be locale-dependent versions (e.g., fo=
r
> > postal codes), and in some cases we can add the necessary logic (e.g.,
> > in the date converter).  Right now there's some configurability to the
> > date converter (month_style), but it's limited, and if the locale is
> > attached to the state then you could support more than one format at a
> > time.
> >
>
> So the solution would be:
>
> 1. Use gettext for the messages (seems that there is only litte change
> to the current code required)
>
> 2. locale dependend validation logic with slightly different semantics
> (e.g date) should be included in the current classes of validators.py
>
> 3. Local specialities schould be provided by seperate specialized
> classes. (e.g postal codes, telephone numbers, StateProvince)
>
> 4. The language, locale setting used should be controlled by an to be
> defined state attribute (1 & 2, 3 is a different class that has to be
> explicitly called by the user). If it is omitted the systems standard
> locale is used. I cannot say where is the best place for that attribute
> because I do not know the code of formencode that much.
>
> If I find the time I=B4ll start changing validators.py to support gettext
> and create the german message file. OK?

--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> FormEncode subversion is hosted at svn.colorstudy.com, not under
> formencode.org.

Ahh, yes of course... I hadn't looked at what i had in my externals..

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Ian Bicking schrieb:

> I don't really know the best way to do internationalization.  But I had 
> intended it to be possible in some fashion -- probably with the logic 
> somewhere in the formencode.api.Validator.message method.  The locale 
> could be passed in attached to the state in some fashion (or in a 
> threadlocal global or somesuch), and could translate the message before 
> doing the substitutions.  The other part then would be extracting the 
> messages so they can be translated.

for the messages there is gettext

http://docs.python.org/lib/node333.html

> 
> But I've never done anything with internationalization, so I'm very open 
> to advise.  For locale-related validators like date and zip code, I 
> think in some cases there should be locale-dependent versions (e.g., for 
> postal codes), and in some cases we can add the necessary logic (e.g., 
> in the date converter).  Right now there's some configurability to the 
> date converter (month_style), but it's limited, and if the locale is 
> attached to the state then you could support more than one format at a 
> time.
> 

So the solution would be:

1. Use gettext for the messages (seems that there is only litte change 
to the current code required)

2. locale dependend validation logic with slightly different semantics 
(e.g date) should be included in the current classes of validators.py

3. Local specialities schould be provided by seperate specialized 
classes. (e.g postal codes, telephone numbers, StateProvince)

4. The language, locale setting used should be controlled by an to be 
defined state attribute (1 & 2, 3 is a different class that has to be 
explicitly called by the user). If it is omitted the systems standard 
locale is used. I cannot say where is the best place for that attribute 
because I do not know the code of formencode that much.

If I find the time I´ll start changing validators.py to support gettext 
and create the german message file. OK?

--
Greg

Kevin Dangoor wrote:
> On 10/5/05, Ian Bicking <ia...@co...> wrote:
> 
>>Kevin Dangoor wrote:
>>
>>>I'm having trouble resolving "formencode.org". sqlobject.org is
>>>working fine for me, though... I would've thought they'd be on the
>>>same server.
>>
>>The DNS expired and I'm having a hard time renewing it;
>>formencode.sf.net still works for now.
> 
> 
> That's weird. This morning, I successfully ran an svn update. I wonder
> how that worked. At the moment, I can't resolve it again.

FormEncode subversion is hosted at svn.colorstudy.com, not under 
formencode.org.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

On 10/5/05, Ian Bicking <ia...@co...> wrote:
> Kevin Dangoor wrote:
> > I'm having trouble resolving "formencode.org". sqlobject.org is
> > working fine for me, though... I would've thought they'd be on the
> > same server.
>
> The DNS expired and I'm having a hard time renewing it;
> formencode.sf.net still works for now.

That's weird. This morning, I successfully ran an svn update. I wonder
how that worked. At the moment, I can't resolve it again.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

Kevin Dangoor wrote:
> I'm having trouble resolving "formencode.org". sqlobject.org is
> working fine for me, though... I would've thought they'd be on the
> same server.

The DNS expired and I'm having a hard time renewing it; 
formencode.sf.net still works for now.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Gregor Horvath wrote:
> hi,
> 
> The messages in validators are english, also there are some locale 
> dependet validations(date, zip code etc.)
> 
> I do need some of them in german. Whats your way/plans in 
> internationalization?
> 
> Should I create a german validators_de.py subclassing the classes from 
> validators.py?
> 
> Are you interested in integrating it in formencode?

I don't really know the best way to do internationalization.  But I had 
intended it to be possible in some fashion -- probably with the logic 
somewhere in the formencode.api.Validator.message method.  The locale 
could be passed in attached to the state in some fashion (or in a 
threadlocal global or somesuch), and could translate the message before 
doing the substitutions.  The other part then would be extracting the 
messages so they can be translated.

But I've never done anything with internationalization, so I'm very open 
to advise.  For locale-related validators like date and zip code, I 
think in some cases there should be locale-dependent versions (e.g., for 
postal codes), and in some cases we can add the necessary logic (e.g., 
in the date converter).  Right now there's some configurability to the 
date converter (month_style), but it's limited, and if the locale is 
attached to the state then you could support more than one format at a time.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Because of the if_empty parameter, the StringBoolean validator in svn
was returning False (not 'false') for from_python(False). This change
fixes that:

Index: formencode/validators.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- formencode/validators.py    (revision 1077)
+++ formencode/validators.py    (working copy)
@@ -1487,7 +1487,6 @@

     true_values =3D ['true', 't', 'yes', 'y', 'on']
     false_values =3D ['false', 'f', 'no', 'n', 'off']
-    if_empty =3D False

     messages =3D { "string" : "Value should be %(true)r or %(false)r" }

@@ -1496,7 +1495,7 @@
             value =3D value.strip().lower()
             if value in self.true_values:
                 return True
-            if value in self.false_values:
+            if not value or value in self.false_values:
                 return False
             raise Invalid(self.message("string", state,
                                        true=3Dself.true_values[0],


--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

hi,

The messages in validators are english, also there are some locale 
dependet validations(date, zip code etc.)

I do need some of them in german. Whats your way/plans in 
internationalization?

Should I create a german validators_de.py subclassing the classes from 
validators.py?

Are you interested in integrating it in formencode?

--
Greg

2005/10/5, Gregor Horvath <g.h...@gm...>:
> Hi,
>
> I am just evaluationg FormEncode and read the docs and played a little
> bit with it.
>
> There is one question left:
>
> How do you do domain specific validation, where fields are dependend
> from each other?


This thread may help too:
http://pythonpaste.org/archives/message/20050913.210509.06cf290b.en.html

--
Ksenia

I'm having trouble resolving "formencode.org". sqlobject.org is
working fine for me, though... I would've thought they'd be on the
same server.

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: ki...@bl...
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com