Practical AOP #2 - What's done behind-the-scene?

I'll show you something that I think it's hard to maintain without AOP.
As in my Practical AOP #1, I mentioned that I have 8 inter-type declarations and 5 pointcuts to make data-binding work in ZK framework.

The main important thing is that I need one of the ZK base class to implement my Bindable interface. This change can be considered as somekind of the architectural change. Other point is that several UI element classes need to be modified. One of my pointcuts weaves to add the special event trigger to, at least, 9 classes.

The figure below partially shows the UML-like class diagram for the data-binding aspect.

AOP | Modularity ~= Responsibility

It's difficult to making change to many opensource projects that their developers are taking full responsibility to their own codes. The process of changing must be done via their process. Many projects use the opensource community to find their bugs rather than feature enhancement becuase the developer still want to control the way the project should be. This is somewhat to crash the innovations. Someone who has some ideas to completely enhace the original project has to *fork* to the new project. In my opinion, we can use AOP to solve these social phenomena.

What I've done is in the same way I mentioned above. At the first place, I want to add some new features to ZK. I created some new code and was thinking about sending the patch to ZK developers. But I stopped and thought again. If I send my patches to them, my code may break their code and it's not good for the ZK community. The development may have to be slow down because something will be patched into the core. So my solution is to convert all my new code into an aspect. Then I'll take all responsibilities to my aspect rather than push it to the ZK core developers. I think this solution could be good when someone wants to contribute a new thing to the core of some working frameworks. That's why the data-binding aspect has been made.

Practical AOP #1: Data-Binding Aspect for Web UI

ZK (http://zk1.sf.net) is one of the best XUL tool for Java that I've known. It's a very powerful framework working on server-side to render DHTML with Ajax capability. ZK is heavily based on MVC model, but I personally want to use the .NET-like data-binding feature in this framework. To avoid making changes direct to the ZK core, which is being maintained by its developers, I use AspectJ (1.5) to create the "data-binding" aspect.

However, I firstly started with OO approach in my development process. After I have some working code, I've tried to refactor the data-binding aspect out of the base code. During development, I've found that it is difficult to develop aspects without looking to the base source code. Because I need to ensure that my aspect weaves the base code correctly.

In my data-binding aspect, I have 5 pointcuts and 8 inter-type declarations.

Result
I've finished the first version of zk-databinding aspect outside the ZK team.
With AspectJ 1.5 and Java 5, I can deploy my aspect to a Web container (tested with
Tomcat 5.5.16) and get the data-binding feature transparently.
Not surprisingly, the data-binding aspect works with ZK 1.1 and ZK 1.2 flawlessly.