Hi,
In a recent mail Paul issued a "warning" about VirtualFields. That coupled
with my recent experience (quite positive by the way), gave me this idea.
Paul's original words are:
>
> > Be aware that the virtual fields will calc every time the grid asks for a
> refresh.
>
> What I was getting at is that you may want to cache the results of the
> getSubtotal()
> function for use by the getBalance() function, instead of calculating the
> subtotal
> once and then again.
>
> Paul
>
That I know of the only way to display non-database data with database on a
grid is to include virtual-fields.
I wonder if it would be possible to to have virtual fields that do not
calcevery time the grid refreshes but are totally dependent on the
user.
What I mean is that these variable fields:
1. would be declared just like virtual field (or some similar way)
2. would not be evaluated (basically the developer would be responsible for
value setting in code)
3. would be databinded to the bizobj and live as long as the bizobj
1. The only difference in declaration is that it would not be necessary to
supply a callable to the VirtualFields property, instead None would be
supplied in order to keep with syntax requirements:
self.VirtualFields.update({"nonCallableVirtualField": None})
2. The chief results here are that there would not be a performance tax (no
calls), and that the developer would not have any code to write besides the
declaration. In some cases this may make a lot of sense.
3. For example. If a user changes a value in a grid, the "
nonCallableVirtualField" of the respective record gets set. If the grid is
destroyed, but the bizobj supporting the "nonCallableVirtualField" lives,
then the value remains in memory. This is useful for passing bizobjs arround
.
This "nonCallableVirtualField" has the potential to replace the "traditional
VirtualField" in many use cases, specially where there are many refreshes to
the grid or big datasets. Also, some usages become absolutely trivial:
* An example is a checkbox in a grid. Instead of setting a list as a bizobj
attribute and checking with the virtualfield function if the record id is in
the list in order to return True or False, you would just have to self a
nonCallable as above!
* What about when several columns are involved, for example two hold
DCheBoxes for some boolean selection, another a dDropdownlist for a user
selection. the user clicks away, and later (perhaps form close or
datasubmisson) the developer parses the data and uses it for whatever
purpose.
I understand this is not a very strong use case (as an argument for the
feature), but I believe others can see better applications (what about
dComboBox?). On the other hand performance alone might just be such an
argument.
Ideas are a dimme a dozen! Does this one make any sense? Is there already a
way to accomplish something similar?
Miguel
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/a19730800905200936k9dc664eye35303ef87151...@mail.gmail.com
