AOP to go

The Aspect-Oriented Programming (AOP) approach attempts to solve crosscutting concerns that are scattered over a project. By describing a concern only once, it can be changed for the whole project without the need to manually change each and every class, part or module of the application implementing such a concern. Thus, AOP enforces the separation of concerns, reduces redundancy and improves quality.
AOP usually works by means of special languages that extend existing languages. However, it is possible to achieve quite similar results with wurblets.

The previous example contains a wurblet anchor to generate the method selectByParentId, like this:
DocumentNode.selectByParentId
(click on the image to view the complete code)

The variable $remote in line 210 tells the wurblet whether to generate code that is 3-tier capable or just 2-tier. The "3-tier-capability" is a crosscutting concern.
Because the wurbelizer has full access to the ant-environment, such variables are usually defined as ant-properties like this:
build.xml

If the property is set to --remote, the wurblets will generate 3-tier code. Otherwise, only 2-tier code will be generated. By declaring this parameter in the project's build file, it controls a crosscutting concern that can be enabled or disabled for the whole application at build-time. The knowledge how to implement the 2- and 3-tier capability is located in the wurblets. Whenever this knowledge changes, the code related to that aspect which is scattered over the whole application changes as well. This is the most exciting feature of AOP!

Notes

to the next example... >