Comments on: Naked Objects and AOP – Part 2 http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/ Ideas and experiences relating to the Naked Objects framework Thu, 01 Apr 2010 10:33:58 +0200 http://wordpress.org/?v=2.8.4 hourly 1 By:   Ich habe das Rad erfunden by Schauderhaftes http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/comment-page-1/#comment-487   Ich habe das Rad erfunden by Schauderhaftes Thu, 03 Apr 2008 19:08:58 +0000 http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/#comment-487 [...] Also wieder einmal das Rad zu spät erfunden. Wikipedia führt sogar noch weitere Raderfinder, oder zumindest Radbauer auf. Aber auch wenn ich wohl nicht als Erfinder in die Analen der Softwareentwicklung eingehen werde, halte ich das Konzept für einen hoch interessanten Ansatz, bei dem es aber sicher noch eine Menge zu tun gibt. Ich bin zum Beispiel weder von der generierten GUI von Naked Objects 100% überzeugt, noch von dem Ansatz wirklich 100% zu generieren. Mindestens für eine Übergangszeit halte ich es für absolut wichtig immer noch die Möglichkeit zu haben einfache einen Dialog zu öffnen und den eigenen GUI-Code dort zu verewigen. Ich werde das Projekt und das Blog von Richard Pawson jedenfalls weiter beobachten, in dem er unter anderem über neue Ideen für das Framework schreibt. [...] [...] Also wieder einmal das Rad zu spät erfunden. Wikipedia führt sogar noch weitere Raderfinder, oder zumindest Radbauer auf. Aber auch wenn ich wohl nicht als Erfinder in die Analen der Softwareentwicklung eingehen werde, halte ich das Konzept für einen hoch interessanten Ansatz, bei dem es aber sicher noch eine Menge zu tun gibt. Ich bin zum Beispiel weder von der generierten GUI von Naked Objects 100% überzeugt, noch von dem Ansatz wirklich 100% zu generieren. Mindestens für eine Übergangszeit halte ich es für absolut wichtig immer noch die Möglichkeit zu haben einfache einen Dialog zu öffnen und den eigenen GUI-Code dort zu verewigen. Ich werde das Projekt und das Blog von Richard Pawson jedenfalls weiter beobachten, in dem er unter anderem über neue Ideen für das Framework schreibt. [...]

]]> By: Richard Pawson http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/comment-page-1/#comment-8 Richard Pawson Tue, 23 Oct 2007 09:35:32 +0000 http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/#comment-8 I was just trying to demonstrate the concept, in order to get the ball rolling. You are certainly correct about needing to include the addToXxx and removeFromXxx methods. Likely you would need quite a few aspects to build a complete solution this way, including the one for intercepting the construction of new object. (Dan pointed out, correctly, that I should also have split even this aspect into two: one that defined the ContainerAwareObject and one that implemented the objectChanged() and resolve()). In regard to injected dependencies (other than the container) I'm not sure there's a problem there. Robert advises me that calling objectChanged() within the setter for an injected dependency (e.g. a Repository or other type of service) should not, in general, cause a problem (that said, I haven't tried that out yet). I had to put in the guard against the injection of the DomainObjectContainer, though, because calling objectChanged() there caused a circularity. On your last comment I think you might have a misunderstanding. My solution does NOT require that your domain objects implement ContainerAwareObject explicitly - that implementation is done by the aspect at compile time. In other words you should still be able to use a POJO domain object without modifying the code. I was just trying to demonstrate the concept, in order to get the ball rolling. You are certainly correct about needing to include the addToXxx and removeFromXxx methods. Likely you would need quite a few aspects to build a complete solution this way, including the one for intercepting the construction of new object. (Dan pointed out, correctly, that I should also have split even this aspect into two: one that defined the ContainerAwareObject and one that implemented the objectChanged() and resolve()).

In regard to injected dependencies (other than the container) I’m not sure there’s a problem there. Robert advises me that calling objectChanged() within the setter for an injected dependency (e.g. a Repository or other type of service) should not, in general, cause a problem (that said, I haven’t tried that out yet). I had to put in the guard against the injection of the DomainObjectContainer, though, because calling objectChanged() there caused a circularity.

On your last comment I think you might have a misunderstanding. My solution does NOT require that your domain objects implement ContainerAwareObject explicitly – that implementation is done by the aspect at compile time. In other words you should still be able to use a POJO domain object without modifying the code.

]]> By: Jan Lessner http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/comment-page-1/#comment-7 Jan Lessner Tue, 23 Oct 2007 09:17:30 +0000 http://blog.nakedobjects.org/2007/10/19/naked-objects-and-aop-part-2/#comment-7 I'm afraid it's not as simple as you proposed. One problem is that you just instrumented the set... methods of the domain object classes, but there ars certainly others to consider too, like addTo... and remove... Even more difficult to achieve is the exclusion of methods being concerned with dependency injection. In your example you are explicitely excluding setters which get passed a DomainObjectContainer which is fairly simple. But what's about other services and factories/repositories which are not known at compile time of the aspects? The exclusion mechanism needs to know about these too, e.g. by parsing them out of nakedobjects.properties. Additionally I understood your solution being based on the idea that the domain classes of interest are supposed to implement a common interface ContainerAwareObject. I believe that this will not be excepted by people who are moving to a POJO approach in other technologies like EJB and JPA. I’m afraid it’s not as simple as you proposed. One problem is that you just instrumented the set… methods of the domain object classes, but there ars certainly others to consider too, like addTo… and remove… Even more difficult to achieve is the exclusion of methods being concerned with dependency injection. In your example you are explicitely excluding setters which get passed a DomainObjectContainer which is fairly simple. But what’s about other services and factories/repositories which are not known at compile time of the aspects? The exclusion mechanism needs to know about these too, e.g. by parsing them out of nakedobjects.properties. Additionally I understood your solution being based on the idea that the domain classes of interest are supposed to implement a common interface ContainerAwareObject. I believe that this will not be excepted by people who are moving to a POJO approach in other technologies like EJB and JPA.

]]>