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