Nope. This would allow one app to change error messages to other apps.
On Oct 23, 10:42 pm, Iceberg <iceb...@21cn.com> wrote:
> > On Oct 21, 12:03 pm, Iceberg <iceb...@21cn.com> wrote:
> > > It is a little bit surprising and happy to see these error_message
> > > draw enough attention. :-) So is it time to also consider my proposal
> > > more than one month before?
> > > http://groups.google.com/group/web2py/browse_frm/thread/8cbe658406be595f
>
> > > That way, we don't even have to adjust the default error_message to
> > > please everyone. Instead we provide a good way to customize the
> > > error_message whenever wanted.
>
> > > What do you think?
>
> On Oct 22, 1:13 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
>
>
> > Yes but.
>
> > This is my I normally do:
>
> > not_empty=IS_NOT_EMPTY(error_message=T('doh!'))
>
> > db.table.field1.requires=not_empty
> > db.table.field2.requires=not_empty
>
> > so no problem with DRY.
>
> > My objection in the thread was not on your idea in principle but on
> > the fact that T does not exist until the app is called. I would not
> > know how to pass T to the validators without a mechanism of hidden
> > hooks and I would rather avoid that.
> > Perhaps you can propose a specific possible implementation that I have
> > not thought of.
>
> > We should also consider that IF T had been hard coded in validators
> > now the proposed change in error messages would not be backward
> > compatible since it would break translations.
>
> > Massimo
>
> Sure when you are using IS_NOT_EMPTY you can use one instance for all,
> so no problem with DRY. But, when you are using IS_IN_DB,
> IS_NOT_IN_DB, IS_IN_SET, etc, you are using different instances so we
> DO need some approach to internationalize or localize the
> error_message, in a DRY manner.
>
> And yes, T can not be called inside validators.py, but at least we can
> provide a way to customize it inside model or controller. That is why
> my second suggestion in my earlier thread, and I don't think it breaks
> backward compatibility. Quote that again as below.
>
> class IS_NOT_IN_DB(...):
> error_message = 'value already in database' # class wide
> def __init__(self,
> ...
> error_message=None,
> ):
> if not error_message:
> self.error_message = error_message
>
> so in app's model file we can:
> IS_NOT_IN_DB.error_message = T('value already in database!') #
> class
> wide
> ...
> db.Field('foo',
> requires=IS_NOT_IN_DB(db,"table.field"))
> db.Field('bar',
> requires=IS_NOT_IN_DB(db,"table.field2"))
>
> Same proposal applies to all other validators.
>
> By the way, based on above suggestion, we can even add one more trick
> into the scaffold "welcome" app, a file named models/i18n.py, which
> contains:
> IS_NOT_IN_DB.error_message = T('value already in database')
> IS_IN_DB.error_message = T('value not in database')
> ...
> That is kind of "how to pass T to the validators without a mechanism
> of hidden hooks".
>
> Is it any better?
>
> Regards,
> Iceberg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
