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 <[email protected]> > 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.
