Have started implementing this story now (ISIS-831), looking for some
opinions. Oscar will chip in I'm sure :-) but I'd like other opinions too,
if possible.
Right now I'm planning to have an @ActionInteraction, @PropertyInteraction
and @CollectionInteraction; these are basically replacements for
@PostsActionInvokedEvent, @PostsPropertyChangedEvent and
@PostsCollectionAddedToEvent/@PostsCollectionRemovedFromEvent, and support
the validation stuff. The original 4 @PostsXxxEvent annotations will be
deprecated.
Because they are intended as replacements, if both annotations are present
then I intend only to generate one event on the event bus.
~~~
You'll note that I've collapsed the two annotations for collections
(add/remove) into a single annotation for collections. I think I prefer
this.
This does raise the question of whether to preserve two event classes for
collections (eg a CollectionAddInteractionEvent and
CollectionRemoveInteractionEvent), or whether to collapse into a single
event and have a field on the event class so that the subscriber can tell
whether an add or remove was performed.
~~~
The first design looks results in more boilerplate for the publisher:
public static class OrderLinesAdd extends CollectionAddInteractionEvent {
... }
public static class OrderLinesRemove extends
CollectionRemoveInteractionEvent { ... }
@CollectionInteraction(add=OrderLinesAdd.class,
remove=OrderLinesRemove.class)
public Set<OrderLine> getOrderLines() { ...}
but is cleaner for the subscriber:
@Subscribe
public void on(OrderLinesAdd ev) { ...}
@Subscribe
public void on(OrderLinesRemove ev) { ...}
~~~
The second design is simpler for the publisher:
public static class OrderLines extends CollectionRemoveInteractionEvent {
... }
@CollectionInteraction(OrderLines.class)
public Set<OrderLine> getOrderLines() { ...}
but results in more code for the subscriber:
@Subscribe
public void on(OrderLines ev) {
if (ev.getType == ADD_TO) {
... add logic ...
} else {
... remove logic ...
}
Of these, I prefer the second design myself - I'd rather keep boilerplate
in the publishing entities down to a minimum. But other opinions welcome.
~~~
Also, I've named the annotations @ActionInteraction, @PropertyInteraction
and @CollectionInteraction, but it occurred to me that they could be
shortened to just @Action, @Property, @Collection. This might be a bad
thing or a good thing:
- it might be a bad thing because it would suggest that the only methods
that are recognised as actions, properties and collections are those
annotated in this way; where as Isis recognises everything that isn't
@Ignore'd.
- it might be a good thing because we could provide a mode of running Isis
whereby all methods are ignored by default unless explicitly annotated. In
that case these annotations would flag the bits of the class that are
significant to Isis.
I think the bad outweighs the good, meaning I should keep the "Interaction"
suffix and keep the current behaviour of recognizing everything unless
@Ignore'd .... but thought it raising in case anyone has any opinions on
this matter.
Thx
Dan
On 3 July 2014 12:21, Dan Haywood <[email protected]> wrote:
>
>
> On 3 July 2014 12:15, GESCONSULTOR <[email protected]> wrote:
>
>>
>> Agree with you, Dan.
>>
>> Simply the @ActionInteraction perhaps should have the @PostsXXX prefix
>> for coherence.
>>
>>
> I thought about that, but I thought that "PostsXxx" implies an event being
> fired after (which used to be the case, of course) whereas in the new
> proposed design there are four events fired, three before the execute, one
> after.
>
> Another alternative I had thought of was to fold this into @Command, eg:
>
> @Command(...., actionInteraction=RemoveActionInteraction.class)
>
> One issue though is that commands only apply to actions, not to properties
> and collections (remember: there is the hide and disable events as part of
> this). So perhaps probably best not too combine just yet, until things
> become clearer.
>
> Other suggestions welcome, of course!
>
>
> Ta
> Dan
>
>
>
>
>> Many thanks!!
>>
>>
>> > El 03/07/2014, a las 12:25, Dan Haywood <[email protected]>
>> escribió:
>> >
>> > @ActionInteraction
>>
>
>
