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.
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, @PostsCollectionRemovedFromEvent, >>>> @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 >>>>>> >>>>>> >>>>>> >
