Ticket #1180 (closed defect: moved)

Many plugins take a display as a parameter but munge it's associated Dataset generating Dataset::update() events. Calling Dataset::update() will set off a chain of events that will eventually call Display::update() on all Displays containing that Dataset.

Currently, declaring a Dataset @Parameter as ItemIO.BOTH will cause DisplayPostprocessor to generate a second Display::update() for all Displays containing that Dataset, which is redundant and potentially wasteful.

However, it is vital that the Dataset be labeled as ItemIO.BOTH because it *is* also an output of the plugin, and downstream code needs to know that.

This ticket came from ticket #1020

I can think of a couple different solutions, but none of them seems obviously and unequivocally best to me:

• All concrete implementations of Display become smart enough that calling update() twice in a row does nothing on the second call, because there is nothing left to do. This would entail more careful tracking of what has changed. It also makes doing a "forced refresh" of the display potentially less intuitive, as we would then need a separate method or toggle for doing that.
• The DisplayPostprocessor somehow becomes smart enough to avoid calling Display::update() on Displays that were already updated during plugin execution, either directly or as part of an event chain, such as when calling Dataset::update(). I am not entirely sure how we would track that though.