When I wrap the delegated property the way you said, I get the following error
Caused by: java.lang.NullPointerException
at
nl.pocos.dom.subscription.SIPSubscription.setOriginatingAdditional(SIPSubscription.java:255)
at
nl.pocos.dom.subscription.SIPSubscription.modifyOriginatingAdditional(SIPSubscription.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
The wrapperFactory is null while the documentation [1] says it should be
registered automatically... The setter does work without the wrapper.
Erik
[1] http://isis.apache.org/reference/services/wrapper-factory.html
________________________________________
From: Jeroen van der Wal [[email protected]]
Sent: Monday, October 06, 2014 1:47 PM
To: users
Subject: Re: eventbus: after property changed
Hi Erik,
You can wrap the delegated entity [1] to enforce business rules:
...
public void setOriginatingAdditional(String originatingAdditional) {
wrapperFactory.wrap(getSipTrunk()).setOriginatingAdditional(
originatingAdditional);
}
...
@Inject
private WrapperFactory wrapperFactory;
HTH,
Jeroen
[1] http://isis.apache.org/reference/services/wrapper-factory.html
On Mon, Oct 6, 2014 at 10:45 AM, Erik de Hair <[email protected]> wrote:
> On 10/06/2014 09:21 AM, Jeroen van der Wal wrote:
>
>> Hi Erik,
>>
>> Do you mean a getter without a setter? Can imagine that that
>> -intentionally- doesn't work. Otherwise share some more code to elaborate
>> on what you are doing.
>>
> Hi Jeroen,
>
> I mean a delegated property (with a delegated setter):
>
> @Optional
> public String getOriginatingAdditional()
> {
> return getSipTrunk().getOriginatingAdditional();
> }
> public void setOriginatingAdditional(String originatingAdditional)
> {
> getSipTrunk().setOriginatingAdditional(originatingAdditional);
> }
>
> where getSipTrunk refers to a related entity.
>
> This doesn't work with the @RegEx-annotation. But I think we should forget
> that for this issue.
>
> The example I shared before (the getCustomerReference code) wasn't on a
> delegated property and didn't work either. So I'll try to get that working
> first.
>
>
>> Cheers,
>>
>> Jeroen
>>
>> On Mon, Oct 6, 2014 at 9:02 AM, Erik de Hair <[email protected]> wrote:
>>
>> Hi Erik,
>>>
>>>> Pretty sure this is all working in 1.6.0; in fact the changes you've
>>>> made
>>>> are (coincidentally?) also part of the todoapp app, as generated by the
>>>> todoapp-archetype;
>>>>
>>>> The changes ARE from the todoapp indeed. But I don't need all the code
>>> from the todoapp so I have to figure out what part I do need. I'll have a
>>> closer look and do some debugging.
>>>
>>> Could it be possible that the @PropertyInteraction annotation is not
>>> working on a derived property? I noticed the @RegEx doesn't work for a
>>> derived property either.
>>>
>>>
>>> mvn archetype:generate \
>>>> -D archetypeGroupId=org.apache.isis.archetype \
>>>> -D archetypeArtifactId=todoapp-archetype \
>>>> -D archetypeVersion=1.6.0 \
>>>> -D groupId=com.mycompany \
>>>> -D artifactId=myapp \
>>>> -D version=1.0-SNAPSHOT \
>>>> -B
>>>>
>>>>
>>>> If you run the above and import into your IDE, then you can set a
>>>> breakpoont on ToDoItemSubscriptions and see it invoked.
>>>>
>>>> @Programmatic
>>>> @Subscribe
>>>> public void on(PropertyInteractionEvent<?,?> ev) {
>>>> recordEvent(ev);
>>>> switch(ev.getPhase()) {
>>>> ...
>>>> case EXECUTED:
>>>> LOG.info("Received PropertyInteractionEvent, " +
>>>> container.titleOf(ev.getSource()) + ", changed " +
>>>> ev.getIdentifier().getMemberName() + " : " + ev.getOldValue() + " -> "
>>>> +
>>>> ev.getNewValue());
>>>> ...
>>>> break;
>>>> }
>>>> }
>>>>
>>>>
>>>> Or, just look at the console:
>>>>
>>>> 06:47:51,939 [ToDoItemSubscriptions 1177678328@qtp-1850527708-1 INFO ]
>>>> Received PropertyInteractionEvent, Buy milk xxx due by 2014-09-30,
>>>> changed
>>>> description : Buy milk -> Buy milk xxx
>>>>
>>>> ~~~~~~~~~~
>>>>
>>>> For your example, the reason why the event is fired when rendered is
>>>> because that will be the hidden phase. In fact, it should be fired
>>>> twice,
>>>> once for hidden phase, once for disabled. This allows subscribers to
>>>> veto
>>>> the visibility/enablement of any given class member being rendered.
>>>>
>>>> HTH
>>>> Dan
>>>>
>>>>
>>>>
>>>> On 26 September 2014 16:16, Erik de Hair <[email protected]> wrote:
>>>>
>>>> Tried to configure like the example.
>>>>
>>>>> What I did:
>>>>> - added EventBusServiceJdo to isis.properties
>>>>> - added @PropertyInteraction for the following property
>>>>>
>>>>> @PropertyInteraction()
>>>>> @Column(name = "klantreferentie", allowsNull = "true")
>>>>> public String getCustomerReference()
>>>>> {
>>>>> return this.customerReference;
>>>>> }
>>>>>
>>>>> - created a subscriptions class like ToDoItemSubscriptions with
>>>>> injected
>>>>> EventBusService and with the following method
>>>>>
>>>>> @Programmatic
>>>>> @Subscribe
>>>>> public void on(PropertyInteractionEvent<?,?> ev) {
>>>>> recordEvent(ev);
>>>>> switch(ev.getPhase()) {........
>>>>>
>>>>> When I edit the entity and change the value of CustomerReference, above
>>>>> mentioned method isn't called. It ís called however when I just open
>>>>> the
>>>>> entity page. Do I need to configure anything else?
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 09/26/2014 10:24 AM, Dan Haywood wrote:
>>>>>
>>>>> Hi Eric,
>>>>>
>>>>>> as Martin says... the @PostsPropertyChangedEvent is deprecated,
>>>>>> similarly
>>>>>> so are @PostsCollectionAddedToEvent, @PostsCollectionRemovedFromEven
>>>>>> t,
>>>>>> @ActionInvokedEvent.
>>>>>>
>>>>>> Instead they have been replaced by the more powerful
>>>>>> @PropertyInteraction,
>>>>>> @CollectionInteraction and @ActionInteraction annotations. The
>>>>>> primary
>>>>>> difference is that these new annotations cause an event to be fired
>>>>>> not
>>>>>> just once after-the-fact, but in fact FIVE times: hide, disable,
>>>>>> validate,
>>>>>> executing (before) and executed (after).
>>>>>>
>>>>>> The hide/disable/validate allow the subscriber to effectively veto the
>>>>>> interaction: a very powerful concept. In Estatio for example we use
>>>>>> subscribers to veto the deletion of an object that has dependent
>>>>>> entities
>>>>>> (makes for better error messages than a referential integrity error
>>>>>> thrown
>>>>>> up by the DBMS).
>>>>>>
>>>>>> For each of these annotations you can either use the generic event or
>>>>>> create a subclass. The latter allows the subscribers to be more
>>>>>> targeted.
>>>>>>
>>>>>> For an example of using the generic events (with a property), see [1],
>>>>>> [2]
>>>>>> For an example of using the specific events (with an action), see [3],
>>>>>> [4]
>>>>>>
>>>>>> HTH
>>>>>> Dan
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/apache/isis/blob/8cbe55c5c91e9300e9a8c0bf197f51
>>>>>> 66329a298a/example/application/todoapp/dom/src/
>>>>>> main/java/dom/todo/ToDoItem.java#L138
>>>>>> [2]
>>>>>> https://github.com/apache/isis/blob/8cbe55c5c91e9300e9a8c0bf197f51
>>>>>> 66329a298a/example/application/todoapp/dom/src/main/java/dom/todo/
>>>>>> ToDoItemSubscriptions.java#L162
>>>>>>
>>>>>> [3]
>>>>>> https://github.com/apache/isis/blob/8cbe55c5c91e9300e9a8c0bf197f51
>>>>>> 66329a298a/example/application/todoapp/dom/src/
>>>>>> main/java/dom/todo/ToDoItem.java#L287
>>>>>> [4]
>>>>>> https://github.com/apache/isis/blob/8cbe55c5c91e9300e9a8c0bf197f51
>>>>>> 66329a298a/example/application/todoapp/dom/src/main/java/dom/todo/
>>>>>> ToDoItemSubscriptions.java#L106
>>>>>>
>>>>>>
>>>>>> On 26 September 2014 09:01, Martin Grigorov <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Looking at the code it is deprecated and the refers
>>>>>>> to org.apache.isis.applib.annotation.PropertyInteraction
>>>>>>> See its javadoc and TodoApp for usage.
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Fri, Sep 26, 2014 at 9:57 AM, Erik de Hair <[email protected]> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I need to do some maintenance (the user doesn't need to know about)
>>>>>>>> after
>>>>>>>> some property changed. I thought I might do this with the event bus
>>>>>>>> and
>>>>>>>> I
>>>>>>>> found @PostsPropertyChangedEvent but no example of how to configure
>>>>>>>> this.
>>>>>>>> Is there any example available?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Erik
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
