Ok, good points, but I'd be careful to support something (this or anything else) for a reason resembling "it's not prohibited, it worked --> needs to be stable". Bugs can be found, lack of documentation too, it's not said that something built on a "bug" or a shortcoming of the code should be supported for the next century :-P I'm not arguing on "should we do it or not" but given it's not documented, at least there's the possibility to discuss wheter it should be or not a "stable" thing. For readonly fields, yep. For inputs, I'd say no (and in any case, it wouldn't be functional, because they're not stored). Given that it's a pretty specific piece of code that "excluded" virtual fields from forms, I'd argue it has been done for a specific reason (or a specific request...). Wheter it is a sound reason or not, unfortunately I really don't recall discussions about it. I'd also vote to add a test case to avoid banging the head again on the subject when it'll be ruled out what to do.
On Wednesday, September 24, 2014 9:09:32 PM UTC+2, Anthony wrote: > > > By definition virtual Fields are something that closely follow the >> functionality of computed fields, but have the "feature" (I wouldn't dare >> to say "added benefit") to be calculated at each time, and not stored in >> the db. >> > > First, there are readonly forms -- no reason not to include virtual fields > there. Second, even in an update form, there are often readonly fields > displayed -- again, no reason to exclude virtual fields. > > >> I don't know about the breaking of backwards compatibility argument.... >> virtual Fields in forms is something that I tend to consider out of scope, >> because usually a "virtual field" "functionality" in a SQLFORM is better >> suited for a SQLFORM.factory. >> > > See above for why virtual fields might be considered in scope. In any > case, the point is moot because this used to work and now it doesn't. I > suppose we could argue it wasn't documented, but the docs say the "fields" > argument takes a list of fields to include in the form and doesn't > explicitly prohibit virtual fields (one could take the fact that virtual > fields worked as an indication that the term "fields" was meant to be > inclusive). On the developers list, I proposed a simple change that would > bring back the old behavior. > > 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/d/optout.
