Hi Dan. Not sure why you say ... >> >> This approach won't work, because we need to replace the reference with a >> different one. It's basically a 2cascade update" of the impacted objects.
I think that there are 2 different (but related) things in your post. 1. When to post an "deleting object" event. 2. How to control (veto) an action by subscriptions. FIRST USE CASE On the first case, let me explain our use case. We have one Entity (Relationship) with another one "extending" it with some other properties (RelationshipRiskInformation) in another Bounded Context (Maven module). We cannot implement referencial integrity as from the Maven module where the Relationship entity is defined, there's no dependency to the Risk module (in order to avoid circular relationships). So we want to be notified when the Relationship is deleted in order to automatically delete the RelationshipRiskInformation. In that case, we have published the event on the "persisting" Lifecycle method, (i.e., that should be invoked before the DN command be enqueued): An, when we intercept it, we properly delete the related RelationshipBCMInformation. In your case, it seems to me that, instead, you could change the references to the replacement entity if you publish the event by means of "eventBusService.post(event)" in the CODE of the action, right before proceeding with "container().remove(domainObject)" code. SECOND USE CASE In your proposal, only one annotation @PostsActionInvokedEvent Is defined, but I think the intention and behavior could be different for each business rule (disabling, validation, execution). - VETOING AN ACTION INVOKATION (VALIDATE) For the next part, what seems to me is that what you want, instead of explicitly invoke "eventBusService.post(...)", an event that can be automatically published BEFORE action invocation, in order to execute some code on an Event Handler and, also, including the possibility to "veto" the action. I would propose something like @PostsActionValidatingEvent(CommunicationChannel.ValidatingEvent.class) In that case, I think that all event handlers subscribed to that event, should act as a means of "Chain of Responsiblity" pattern, where any of them could "veto" the action invokation with a message, for example. CommunicationChannel.ValidatingEvent.class should be a descendant of a DomainEvent subclass where Isis could, for example, pass the action and invoked params in a Map, and also a "token" field that indicates if the action invocation must be vetoed or not (with a "VALIDATION" message) - i.e., if at least one of the event handlers marks it as invalid it shouldn't execute it. - EXECUTING AN ACTION For the next part, what seems to me is that what you want, instead of explicitly invoke "eventBusService.post(...)", an event that can be automatically published BEFORE action invocation, in order to execute some code on an Event Handler and, also, including the possibility to "veto" the action. I would propose in fact 2 different events: @PostsActionInvokingEvent(CommunicationChannel.RemovingEvent.class) Whose event is posted BEFORE effectively executing the action. In that case, all event handlers would be invoked, but any of them could "veto" the execution. If an exception is thrown, the EvenBusService will act as currently implemented (aborting if it's a descendant of an Isis exception, ignoring it if not). And @PostsActionInvokedEvent(CommunicationChannel.RemovedEvent.class) whose event is posted AFTER the action has been SUCCESSFULLY invoked. In that case, all event handlers would be invoked, but any of them could "veto" the execution because it has already been executed. - DISABLING AN ACTION (DISABLE) I think that this case is different, as the Viewer must know if the action is enabled when drawing the UI (and also in other cases, i.e., BDD tests) and, for that, action shouldn't be executed (which could change the "State" of the Domain). So a different kind of base event would be needed, like @PostsActionDisablingEvent(...) And all event handlers, like on the validation case, acting as a means of "Chain of Responsiblity", could mark the action as "Disabled". GENERAL COMMENT In all previous cases, there's a requirement to explicitly annotate the action with the corresponding @PostsXXX annotation. Perhaps Isis could provide a "generic" mechanism to subscribe to all action invocations, domain object lifecycle events, etc. that wouldn't require to explicitly annotate them. That way would be possible to intercept and "change" the behavior of a given Domain Module developed by Isis, simply by intercepting those platform-level events. HTH, Oscar El 01/07/2014, a las 00:20, Dan Haywood <[email protected]> escribió: > I've raised ISIS-831 [1] to summarize my ideas on this... any feedback > welcome. > > Thx > Dan > > > https://issues.apache.org/jira/browse/ISIS-831 > > > On 30 June 2014 10:04, Dan Haywood <[email protected]> wrote: > >> Hi Oscar, >> thanks for the quick response; within >> >> On 30 June 2014 08:00, GESCONSULTOR <[email protected]> wrote: >> >>> Se has a similar use cases to this one, when an event should be published >>> when the user wanted to remove the domain object. >>> >>> We can publish the event (eventBus.post(...)) on the "removing" lifecycle >>> method. >>> >>> As it's executed in the context of the same transaction where we change >>> the references in all other objects, DN hasn't dispatched the delete >>> command, no references to deleted objects are kept on the database. >>> >>> Shouldn't it be enough for this case? Perhaps I'm missing something. >>> >>> >> >> This approach won't work, because we need to replace the reference with a >> different one. It's basically a 2cascade update" of the impacted objects. >> >> Dan >> >> >> >> >> >> >>> >>> Óscar Bou Bou Responsable de Producto Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO 20000, ITIL-F 902 900 231 / 620 267 520 http://www.twitter.com/oscarbou http://es.linkedin.com/in/oscarbou http://www.GesConsultor.com Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
