Dan Haywood created ISIS-1045:
---------------------------------
Summary: New domain events are created for each phase for
properties, but not for collections nor actions. The current design doesn't
support use of the wrapper factory.
Key: ISIS-1045
URL: https://issues.apache.org/jira/browse/ISIS-1045
Project: Isis
Issue Type: Improvement
Components: Core
Affects Versions: core-1.7.0
Reporter: Dan Haywood
Assignee: Dan Haywood
Priority: Minor
Fix For: core-1.9.0
In the domain events design we have 5 phases:
hide/disable/validate/pre-execute/post-execute. The framework attempts to
reuse the same event where possible
for actions:
- for hide, always creates new event
- for disable, always creates new event
- for validate, always creates new event, puts onto thread-local
- for pre-execute, uses the event from validate (obtain from thread-local)
- for post-execute, uses the event from pre-execute (passed as local var).
for collections:
- ditto
but for properties, although we originally had the same algorithm, this was
changed (patch from Oscar) to:
- for hide, always creates new event
- for disable, always creates new event
- for validate, always creates new event, puts onto thread-local
- for pre-execute, always creates a new event (ignores that on thread-local)
- for post-execute, uses the event from pre-execute (passed as local var).
The reason that Oscar needed this change was because the framework does not
anticipate there being more than one "pending" interaction. However, if the
wrapper factory is used, then this assumption isn't true, because validateX()
-> wrap -> validateY().
This use case actually needs a stack of pending interaction events to support
this change.
As things stand:
* the getUserData() functionality is broken for property domain events
* the underlying problem remains for actions -> actions using the wrapper
factory during the validate phase.
There is also a suggestion that the Guava event bus might be an issue in that
it buffers changes; I'm not exactly sure what this means (we don't use the
async guava bus), and I don't know if its behaviour is significant or not.
But in any case, the above design defect is an issue irrespective and which
needs addressing; once that's fixed then we can look at the Guava event bus to
decide if it is also a problem for us or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
