On 20 Aug 2012, at 8:22 PM, Massimo Di Pierro <massimo.dipie...@gmail.com>
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.
> >
>
>
>
> --
>
>
>
--
