Some people seem to have either too much time in their hands or are exorbitant effective spending time and energy in order to produce beauty in a browser. Take a look at YUI in combination with Yahoo.ext: just for the sake of showing an example, Jack Slocum, the creator of Yeahoo.ext, has build a rich frontend on top of a well known php based discussion system. Prabably the first time I see a rich internet framework/toolset/library coming with a decent and out of the box useful example. Pretty cool I think!! (now sit and wait untill the GWT’s, the Echo2’s, the Dojo’s and the whatever ajax branded yet to come personal-but-o-so-aha-good-looking-investments are coming with their version of dynamic skins for phpBB 
)
This should have been posted yesterday but just listen to the podcast or read the transcript from the team that gave use one of my favourive programming toys.
[bandwagonesque mode on]
Back in the nineties OO Developers were either hard core c++ hackers or a more modest but effecient python programmers (or maybe japanese lone wolf ruby writers). Nowadays, script language practitioners are called script-kiddies and real developers use Java or C#. Ten years ago programming was all about compiling your human readable files into native machine code, today we talk about managed execution. Meanwhile dynamic langauges have always been subject to native interpreters, which during the years have been optimized in every possible dimension to get them performing. But also this niche of software development is moving. 2006 will be known as the year microsoft shipped IronPython and sun brought in the JRuby developers (Does that mean after the movement from sourceforge to codehaus, the project will move again to java.net???) Within a few years C# and java developers will become the old fashioned hackers and the rest of the programming population does OO in a more dynamic way. Want to follow the buzz?, see google’s visualizations here and here (and probably in the future here also)
[bandwagonesque mode off]
By the way, do not forget to attend the JRuby on Rails Javapolis session this year. And another by the way, and that is why I used the bandwagonesque tags, non-mainstream languages and the concept of managed execution is not something new. Boo and Groovy are just two codehaus examples but I think Scala and Nice are also worth mentoning. And as a final by the way, this slightly sceptical view on scripting languages just made me realise I started my career ten years ago with the most underappreciated scripting language in existence
Sometimes a simple one liner found deep down in some active message forum thread is worth a seperate blog entry.
> Apollo is cross-platform desktop technology mix that
> allows you use Flex/xHTML/Ajax/PDF on desktop, use
> filesystem, DBs, networking and so forth.
“what you describe, is a mess not an environment.”
This quote, coming from (yet another) Javalobby discussion about the future of java on the desktop, hits the nail right on the spot. Due to the lack of a decent environment for application distribution we’re trying to fullfil the needs of richness with a mess of browser techniques that make application development look ancient again. We have spoiled our end users with the most fabulous human-being to machine interfaces and meanwhile, due to some rediculous narrowminded views on how end-users are allowed to access applications (actually do their job), we have been selling ‘no, sorry, not possible, technically unattainable’ for too many years. And instead of looking at a feasible solution for this problem, which indeed must be found in an environment and not in a trick, we keep on messing around with whatever technique as long as it is applicable within a browser. At this years JavaOne, Aerith has shown what is possible. The future of Java on the desktop is not a question, it is an idle void waiting to be filled. Maybe it is time to replace the internet browser for the sake of richness?
After my initial explorations of the AspectJ-support offered by Spring, someone (actually, I think it was google again) pointed me to this article about the drawbacks of proxied aop. A good read written by Vincent Partington that shows the internals of how and why a proxy based aop framework can ignore your carefully injected aspects. A ‘must-be-aware-of’ for every Spring 2.0 user!
One commenter on Vincent’s entry suggested one could use the not so stunning but efficient AopContext.getCurrentProxy() call instead of refering to the ‘this‘ pointer. Besides being not beautiful (actually it is butt ugly but that’s a matter of taste which reminds me that programming just like cooking is actually all about (good) taste), getting hold of a proxied twin is in complete contradiction with all principles of aop: Code and cross cutting concerns should be seperated. The fact code needs to be aware of being proxied is more a showstopper than a workaround.
Nevertheless, once accepted this contradictious aproach, the idea came in mind to address this as just an aspect of implementation, an architectural constraint so to speak: ‘Every class or method that is subject of being proxied must be aware of its proxy object‘ (Note, I still do not agree with this rather bold statement, it is just a hypothetical aspect that I’m using for the sake of the nation to have some fun with Spring AOP). How can such an aspect being implemented using Springs AOP features?
First of all, somehow a mechanism must be in place to denote proxy aware classes. To do so, I introduced a special annotation:
public @interface Proxied {}
And of course some point cuts reflecting the usage of this annotation are required:
@Pointcut(”@within(com.logicacmg.acsa.annotations.Proxied)”)
public void withinProxiedType() {}
@Pointcut(”@annotation(com.logicacmg.acsa.annotations.Proxied)”)
public void executingProxiedMethod() {}
The first pointcut refers to classes declared with the @Proxied annotation, the second one refers to the execution of methods decorated with this annotation. Note the subtile difference, the second pointcut gives a fine grained approach were to intercept and were not.
After the pointcut definitions, it is time for some goofy advice how to deal with the proxied execution of methods:
@Before(”(withinProxiedType() || executingProxiedMethod()) && this(proxy)”)
public void beAwareOfProxiedExecution(JoinPoint jp, Object proxy) throws Throwable {
// ….. ????
}
A dirty (but what the hack, the whole problem smells) trick injecting the proxy into the usual suspecious subjects can be used at the // ….. ???? location. And for that, I’ve mixed the advice with some reflection sugar under the assumption every proxy aware class has declared a member field called ‘proxy’. The code is to long to post here but without field caching and exception catching it looks like this:
jp.getTarget().getClass().getField(”proxy”).set(jp.getTarget(), proxy);
Instead of using ((MyService)AopContext.getCurrentProxy()).someMethod it is now possible to use this.proxy.someMethod and as a bonus not every but only an exclusive set of classes is effected.
So what have I learned from this expedition? Well, not so much about the dangers of proxied aop, the previously mentioned article already let me frown. And not so much about proxy awareness either, that seems to be some kind of wicketness by nature. But more about the possibility to define annotations and put the actual semantics of these annotations in seperate aspects. And whether that is evil or not, is probably again a matter of taste. But at least it is a funny and even elegant way of processing annotations using Spring AOP.
