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? On Monday, 20 August 2012 16:36:22 UTC-5, Jonathan Lundell wrote: > > On 20 Aug 2012, at 10:32 AM, Massimo Di Pierro > <[email protected]<javascript:>> > 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 <[email protected]> > 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. > > > > > --
