I suppose something like this would be more useful if you could register
the on_define sometime after the initial table definition. For example, you
might want to add some custom validators to some db.auth_user fields after
calling auth.define_tables(). In that case, you might do something like:
db.register_on_define('auth_user', my_on_define)
Anthony
On Monday, August 20, 2012 11:37:33 PM UTC-4, Jonathan Lundell wrote:
>
> On 20 Aug 2012, at 8:22 PM, Massimo Di Pierro
> <massimo....@gmail.com<javascript:>>
> wrote:
>
> How is this different than
>
> Field(...readable=True)
>
> You still have to put the readable=True somewhere. Why put it in a
> callback (ondefine) instead of where it belongs?
>
>
> It's not necessary in this example. I use stuff like that where I want to
> make the requirements conditional on the controller/function that's being
> called.
>
> More generally: why does *anyone* put requirements outside the Field
> constructors? There are plenty of them in the book. The point of the
> construct I'm proposing is to permit it, for whatever reason, but lazily.
>
>
> On Monday, 20 August 2012 16:36:22 UTC-5, Jonathan Lundell wrote:
>>
>> On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro <massimo....@gmail.com>
>> wrote:
>> > can you show a proof of concept?
>>
>> Not exactly a proof, but a concept.
>>
>> At the very end of lazy_define_table, just before 'return table':
>>
>> if args.get('on_define'):
>> args.get('on_define')(table)
>>
>> The caller-defined on_define function can do things like:
>>
>> def on_define(table):
>> table.field.readable = True
>>
>> or, more interestingly:
>>
>> def on_define(table):
>> if request.something == whatever:
>> table.field.readable = True
>>
>> ...etc. Assuming that there's dynamic stuff like that going on, it saves
>> having to figure out whether you're in a request in which the table is
>> going to be instantiated and then modify the fields.
>>
>> One more thought, just an abstract one because I don't have an example to
>> offer. Since we're storing args at define_table time, to be used later when
>> the table is referenced, it's important that the caller not include mutable
>> objects in args and change them (in relevant ways) between the define_table
>> call and the instantiation.
>>
>>
>> >
>> > On Monday, 20 August 2012 11:51:27 UTC-5, Jonathan Lundell wrote:
>> > On 18 Aug 2012, at 1:46 PM, Massimo Di Pierro <massimo....@gmail.com>
>> wrote:
>> >> As Bruno says. Something like this will completely nullify the benefit
>> of lazy tables.
>> >>
>> >> Field(..., readable=True) is OK but
>> >> db.table.field.readable=True is BAD because will force db.table to be
>> instantiated.
>> >>
>> >
>> > Here's a vague idea: suppose define_table had a requirements parameter,
>> defaulting to None, that could be set to a function (lambda or otherwise)
>> that would be called after the table is instantiated? Then you'd still be
>> able to pull your dynamic requirements into one place, but without
>> triggering define-time instantiation. For convenience, the function would
>> be called for any instantiation, even a non-lazy one, so one could turn
>> lazy instantiation on & off for testing without changing it.
>> >
>>
>>
>>
> --
>
>
>
>
>
>
>
--
