[
https://issues.apache.org/jira/browse/ISIS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327254#comment-14327254
]
Dan Haywood commented on ISIS-1045:
-----------------------------------
as per my email on the dev ML, don't intend to do anything for 1.8.0, but need
to find a solution we're all happy with for 1.9.0.
My preferred solution is to revert the change made in Oscar's patch, and beef
up the threadlocal so that it's a stack of interactions, rather than the
current one. Also I suspect that Guava event bus isn't actually an issue here.
> 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)
