On Sunday, October 27, 2013 8:40:18 PM UTC-4, mr.freeze wrote: > I wouldn't say the use case is odd but it's definitely complex. Then > again, without a context for custom widgets to operate in (i.e. no > knowledge of the record or form that they are bound to) only simple use > cases are possible. Represent and widget are output/input analogs but for > some reason represent has access to the whole row whereas widget only gets > the field value. I will propose a patch if it can be done unobtrusively > and without coupling Field to SQLFORM any further. >
If a field requires special formatting depending on the values of other fields in the form, presumably that special formatting should apply in create forms as well as in edit forms when the values of the other fields are changed. Those cases require client-side logic. So, perhaps the rationale for not passing the record to the widget is that having the widget attempt to handle inter-field formatting dependencies would be inadequate and should therefore be handled entirely via JS (rather than having server-side logic handle the initial loading of edit records, with redundant JS logic to handle create forms and dynamic changes in edit forms). Out of curiosity, what is your use case? Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
