As I said at the end of my previous post: "Of course the latter case should have better approach. Here I am just demostrating when and when not to use Field(..., compute=...) "
The point here is I wanna figure out the scenario for all those not-so- obvious parameters of Field(...), such as compute, authorize, update, etc. Some answers can be found via google "web2py Field foo", some don't. And so far the official book seems contain no chapter for that. [1] is too simple, and [2] is outdated. [1] http://web2py.com/book/default/section/6/3 [2] http://web2py.com/book/default/docstring/Field On May12, 11:32pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > Why would you want web2py to auto-compute a field when you have asked > the user for its value? unless you want the computation BEFORE you > prompt the user for a value. But in this case it cannot depend on > other fields because they have not been insrted yet. > > On May 12, 9:30 am, Iceberg <iceb...@21cn.com> wrote: > > > > > So if I understand it correctly, the Field(..., compute=...) is only > > suitable for defining a field which is not supposed to be showed in > > SQLFORM(), neither supposed to be filled by human. > > > For example, this case can use Field(..., compute=...). > > > db.define_table('circles', > > Field('radius', 'double'), > > Field('area', 'double', > > compute = lambda record: record['radius']**2*3.14), > > ) > > > And this case should not. (Why? Try.) > > > db.define_table('visitor_booking', > > Field('adult', 'integer'), > > Field('kid', 'integer', > > compute = lambda r: min(r['kid'], r['adult']) ), > > # each kid must be accompanied by one dedicated adult > > ) > > > PS: Of course the latter case should have better approach. Here I am > > just demostrating when and when not to use Field(..., compute=...) > > > Regards, > > iceberg > > > On May12, 2:22am, Iceberg <iceb...@21cn.com> wrote: > > > > Thanks for the tip, but there seems some more subtle difference > > > between form.accepts(..., onvalidation=callback) VS Field('bar', > > > compute=lambda r:r['foo']). > > > > The latter will cause that field no longer showts up in SQLFORM, > > > because its default self.fields excludes all compute field. Is there > > > any reason for that? > > > > Right now I still have to stick to my form.accepts(..., > > > onvalidation=callback) approach. :-/ > > > > Sincerely, > > > Iceberg > > > > On May12, 1:30am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > > Yes but > > > > > Field('bar', compute=lambda r:r['foo']) > > > > > not > > > > > Field('bar', compute=lambda r:r.foo) > > > > > On May 11, 11:28 am, Iceberg <iceb...@21cn.com> wrote: > > > > > > I must miss the "compute" feature. Now I am picking it up. Would you > > > > > please confirm whether my understanding is correct? > > > > > > The code: > > > > > Field('bar', compute=lambda r:r.foo) > > > > > is an easier equivalent for: > > > > > def callback(form): form.vars.bar = form.vars.foo > > > > > form.accepts(..., onvalidation=callback) > > > > > and it only works before inserting or updating a record into db. > > > > > > On the contrary, rows.setvirtualfields(...), only works when > > > > > retrieving records from db. (Detail > > > > > inhttp://groups.google.com/group/web2py/browse_frm/thread/d93eee8cc2495c8c > > > > > ) > > > > > > Is it right? > > > > > > Regards, > > > > > iceberg
