> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
