On 7 May 2014 08:53, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> > Hi, Dan. > > It makes all sense, but the problem we've found is when the property is > @Hidden or @Disabled. In those cases, calling > this.wrap(domainObject).setXXX throws an exception. > > If we had business logic implemented inside the modifyXXX method, the only > way for it to be executed if the property was disabled was to directly call > this.domainObject.modifyXXX, in order to avoid the Isis exception. > In working on ISIS-550 (event bus), I encountered the same issue. If you've looked at the code in the ISIS-550 branch that I pushed this morning, you'll see that my solution there was to introduce a "wrappedPolicy" on the PostsXxxEvent annotations, as a hint to the wrapper to not enforce the business rule checks. But from what you've just said, perhaps it'd be better to promote this to a full-blown annotation in its own right? Or, perhaps even better again, maybe wrap(...) should simply be overloaded to return either a wrapper that performs business rule checks, or a wrapper that doesn't? Thoughts welcome Dan > > In the test I've seen that the exception was expected, without the object > being wrapped? That was confusing me... > > @Test > 77<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l77> > public void cannotUseModify() throws Exception { > > 78<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l78> > > 79<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l79> > expectedExceptions.expectMessage("Cannot invoke supporting method for > 'Description'; use only property accessor/mutator"); > > 80<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l80> > > 81<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l81> > // given > > 82<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l82> > assertThat(toDoItem.getDescription(), is("Buy bread")); > > 83<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l83> > > 84<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l84> > // when > > 85<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l85> > toDoItem.modifyDescription("Buy bread and butter"); > > 86<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l86> > > 87<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l87> > // then > > 88<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l88> > assertThat(toDoItem.getDescription(), is("Buy bread")); > > 89<https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4#l89> > } > > > > > > > El 07/05/2014, a las 00:09, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > > Hi Oscar, > > I don't think I explained myself well enough. > > If the domain object has modifyXxx() and setXxx(), then calling: > > this.wrap(domainObject).setXXX(...); > > will in fact cause the modifyXxx() method to be called rather than the > setXxx() one. That is, the proxy looks for the PropertySetterFacet, and > invokes it. When there's a modifyXxx() and a setXxx(), it finds the > PropertySetterFacetViaModifyMethod. > > > The idea is that the "set" represents the "essence" of the interaction ("I > want to set a property of this object"); the fact that it translates to > calling the modifyXxx method is (in a sense) internal to the contract > between the framework and the pojo. > > ~~~ > > Thus: if you are calling modifyXxx anywhere, you just need to change to > call setXxx instead. > > Hope that makes sense? > > Dan > > > > On 6 May 2014 10:45, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote: > >> Hi Dan. >> >> Many thanks for pointing this :-)) Excuse me I didn't read it before. >> >> >> All seems ok for us, but when you say that the modifyXXX cannot be >> invoked (as seen on the TodoItem.modifyDescription(...) test in [1]) this >> can break some code for us. >> >> Let me explain. >> >> We normally use: >> this.wrap(domainObject).setXXX(...); >> >> for setting properties. >> >> This way, if there's any logic associated when updating the property (by >> means of a modifyXXX(...) method), that business logic is always execute >> whereever it's called in the domain. >> >> When we see in the code something like: >> >> domainObject.setXXX(...); >> >> we know it's an error, unless there's a comment like this ones: >> >> // Always Disabled. >> domainObject.setXXX(...); >> >> or >> >> // Always Hidden. >> domainObject.setXXX(...); >> >> >> In those cases, if there's business logic associated, the only way to >> execute it is to explicitly invoke it as in: >> >> domainObject.modifyXXX(...); >> >> >> If that's forbidden now, is there a better way to solve this? >> >> Many thanks! >> >> Oscar >> >> >> >> >> >> >> [1] >> https://git-wip-us.apache.org/repos/asf?p=isis.git;a=blob;f=example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integration/tests/props/ToDoItemTest_description.java;h=11e5ae315f1bc33241658999d4178b06d65c1c9b;hb=074d2c4 >> >> >> >> El 02/05/2014, a las 19:37, Dan Haywood <d...@haywood-associates.co.uk> >> escribió: >> >> >> Hi all, >> >> Just a quick update on some recent commits [1], [2], [3]. (Oscar, take >> especial note, because of how you are wrap(...) all domain objects). >> >> The implementation of WrapperFactory uses cglib 2.x/asm 3.x, which is >> incompatible with Java 7. Although cglib 3/asm 4 are compatible, in the >> past we've had dependency convergence issues with these very popular >> libraries. >> >> So, I've been working through our dependencies on cglib and looking to >> replace them with javassist (JBoss' library). >> >> Specifically: >> - in our JMock mocking we used to use the cglib-based ClassImposterier; >> I've now implemented a new JavassistImposteriser >> - in WrapperFactoryDefault, this similarly has been changed to use >> Javassist. The original implementation is still available, renamed to >> WrapperFactoryCglib. >> >> We still have dependencies on cglib in ObjectFactoryCglib, but this is not >> used by the JDO Objectstore (it is to support lazy loading of the other >> not-released objectstores). >> >> And there was also a cglib/asm dependency in the Wicket viewer, which I've >> also removed. >> >> ~~~ >> So, this is just a heads-up that as of the next release >> WrapperFactoryDefault is using javassist under the covers. >> >> I also fixed one bug: the idea I had was to disallow calls to >> foo.modifyBar), even if such a method existed; instead only >> foo.setBar(...) >> must be called. This wasn't being checked for correctly. It won't >> impact >> your code if you don't use the modifyXxx() supporting method. >> >> ~~~ >> OK, that's it. Have a good weekend! >> >> Cheers >> Dan >> >> [1] https://issues.apache.org/jira/browse/ISIS-569 >> [2] https://issues.apache.org/jira/browse/ISIS-770 >> [3] https://issues.apache.org/jira/browse/ISIS-772 >> >> >> >> Óscar Bou Bou >> Responsable de Producto >> Auditor Jefe de Certificación ISO 27001 en BSI >> CISA, CRISC, APMG ISO 20000, ITIL-F >> >> <contactenos.html.gif> 902 900 231 / 620 267 520 >> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou >> >> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou >> >> <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/> >> >> <gesconsultor_logo_blue_email.png> >> >> >> 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. >> >> >> >> >> >> > > > *Ó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 <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. > > > > > >
