[
https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333136#comment-14333136
]
Oscar Bou commented on ISIS-1045:
---------------------------------
I agree this is irrespective of Guava's queueing behavior (Commented in another
ticket).
But please don't revert patch for having access to user data without supporting
multiple actions executed through the wrapper factory.
> 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)
