Maybe it might be helpful to call this concept "lazy models"? After all, you can put all the requirements you like in controllers/functions; you wouldn't be concerned about lazy models at that point.
On Tuesday, August 21, 2012 4:37:33 AM UTC+1, 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. >> > >> >> >> > -- > > > > > > > --