A quick note on computed fields. Comments and advice welcome. I don't know if
there is a place for this kind of thing in the docs.
the field value is computed with a formula each time the document is
opened, and it is saved each time the document is saved.
The semantics of this field type is rather interesting.
Every time you view the document, the field may display something different,
with or without reference to the value of the field.
When you save the document, the result of the computation is stored as the
So what's the difference between this one and a "Computed for display"
- It's simpler for other formulas to get the value using `doc.getItem`.
However the value retrieved in this way may be totally different from
that returned by `doc.computeFieldValue` (used when displaying the field).
- It's heavier to store than a "Computed for display" field (but only if it
actually stores something).
- It can be lighter to compute than a "Computed for display" field (do the
heavy computation upon save, and use the stored value as a cache until
the next save). For this the formula needs to distinguish whether it's
called during a save or during a view.
Another important difference is about indexing: a Computed field can be indexed (and a Computed for display field cannot)
So it can be used to perform dbsearch or as a column in a view.
Nevertheless, the "computed evrytime but stored only on save" behaviour is quite confusing indeed.
At the origin, we had Computed, Computed for display and Computed on creation modes, now there is a new field mode: Computed on save.
I think Computed should be now deprecated, we should use Computed on save if we want to store the value, and Computed for display if we do not want to store the value (ad recompute it everytime).
It's an interesting balance.
Should Plomino provide more, simpler primitives?
Or should it provide bigger, more complex building blocks?
The current behaviour of the Computed field (and more) can be built using a combination of Display and other fields. E.g. the "Display" field can do much more than display: it can modify Editable or ComputedOnSave fields when it is displayed, and call .save() on the document.
The main downside that I can see is that adding/removing Plomino fields via the Plone content management interface is not something you want to do for fun, so you don't want to use two fields if one will do. It's rather unwieldy. However this can be addressed later with some UI work.
On the balance I like simpler primitives.