ok, in trunk.
On Jan 3, 8:34 pm, Fabiano <fabianoeng...@gmail.com> wrote:
> Ok. By the way, If I may suggest, it would be a nice feature, and backward
> compatible. As the id is an implied column and you must specify it explicit
> when making references, I think it it would be even more consistent to
> specify a table, the id would be implicit in both cases.
>
> Regards,
>
> On Monday, January 3, 2011 11:23:46 PM UTC-2, mdipierro wrote:
>
> > The error is in the example. IS_IN_DB *never* accepted a table as
> > second argument.
> > Sorry for the confusion. Will fix the example.
>
> > Massimo
>
> > On Jan 3, 6:25 pm, Fabiano - deStilaDo <fabian...@gmail.com>
> > wrote:
> > > Hi,
>
> > > from validators.py:
>
> > > 342 class IS_IN_DB(Validator):
> > > 343 """
> > > 344 example::
> > > 345
> > > 346 INPUT(_type='text', _name='name',
> > > 347 requires=IS_IN_DB(db, db.table, zero=''))
> > > 348
> > > 349 used for reference fields, rendered as a dropbox
> > > 350 """
>
> > > But I can't use the documented syntax: IS_IN_DB(db, db.table). I had
> > > to use explicit db.table.id as argument.
>
> > > It looks like the current code (1.91.6) does not accept a table as
> > > argument. Apparently, it cannot figure out that when you specify a
> > > table instead of a field it should use the table's id field. It relies
> > > on the field representation as string to extract the field name,
> > > splitting it by dots, as shows line 371 from the class' constructor:
>
> > > 370 self.field = field
> > > 371 (ktable, kfield) = str(self.field).split('.')
>
> > > Wouldn't be better to test the argument with something like isinstance()
> > first?
>
> > > Sorry if I misunderstood something, but I think that if this is not a
> > > bug, then the documentation should be updated.
>
> > > I also didn't check the code for IS_NOT_IN_DB(), but I guess this
> > > class may have the same issue.
>
> > > Regards,
>
> > > Fabiano.
>
>
