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
>
> 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.
>
>
>
>
>
>
