I saw on your commits a wrapNoExecute(...) or similarly named method.
It would ok.
Not sure what you mean by an annotation....
El 07/05/2014, a las 22:14, Dan Haywood <d...@haywood-associates.co.uk>
escribió:
>
>
>
>
>> 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 public void cannotUseModify() throws Exception {
>> 78
>> 79 expectedExceptions.expectMessage("Cannot invoke supporting
>> method for 'Description'; use only property accessor/mutator");
>> 80
>> 81 // given
>> 82 assertThat(toDoItem.getDescription(), is("Buy bread"));
>> 83
>> 84 // when
>> 85 toDoItem.modifyDescription("Buy bread and butter");
>> 86
>> 87 // then
>> 88 assertThat(toDoItem.getDescription(), is("Buy bread"));
>> 89 }
>>
>>
>>
>>
>>
>>
>>
>>
>>> 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
>>>>
>>>> <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
>>
>>
>>
>>
>> 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.
>
