I've been giving a lot of design consideration to jSeamless 2.0 and if you've been looking at the repository you'll see there's a ton of code that has already been written for it. However, I'm determined that this next version be the perfect UI (well...I'm trying) framework, so I'm giving each step in the development a lot of thought.
One of the major issues I've been thinking about has to do with bean properties. If you keep up on my blog you'll see a lot of ranting to do with how much Java sucks at bean-binding, property change events, and delegates. Well, for jSeamless this is a very important issue since the implementation has to be notified in real-time when a property of a jSeamless Component changes. Up to this point I've been using my handy-dandy MagicBeans framework, but there are a few down-sides to it: 1.) It requires AspectJ to work, 2.) It's magic, and truly freaks people out when they understand what's going on.
Also, I'm investigating my new NumericAdjuster system that will allow you to define how numeric values will "adjust" towards their new value (ex. x = 50 and you set x to 200 instead of just jumping there, if a NumericAdjuster was assigned to x for that Component it would move towards 200 at the rate and easing defined within the adjuster) as a replacement to effects in jSeamless.
This has led me down the path to consider an idea created by another person:
https://bean-properties.dev.java.net/tutorial.htmlThis would diverge us from having the normal component.getX(), component.setX(double) methods and use a component.x.get() and component.x.set(double) alternative with a public Property<Double> representation of "x" in the middle. For NumericAdjuster I could simply extend Property for anything that should support NumericAdjusters and add a setAdjuster method. This would not only serve to clean up, but better hierarchically define values. Further, it would allow change notification to occur immediately by listening to properties when their setter is invoked. The down-side is that this breaks all standard bean conventions and that is something I don't take lightly. So, as the question says, should we divert from Java Bean standards in 2.0 given the advantages this offers?
Poll
