06.02.07

Validation Framework Consolidation : where are we ?

Posted in Java at 8:20 am by skoobi

A Validation Framework Consolidation JSR was started last year. Like others, I appreciate the initiative, but given that there’s not much activity around this JSR, are we going to see some consolidation in this area anytime soon ?

Anyways, just a note explaining why I think it IS a good idea to consolidate the validation frameworks :

More and more people are now pushing Domain Driven Design (DDD), which is more or less a clear re-affirmation of what a good Object-Oriented Design of the Domain (e.g. business logic) is supposed to be. Basically, DDD is what everybody learned at school while studying UML (remember those Software engineering courses : Cars, Drivers,… ?), but nobody applied because it is too easy to forget about that and focus on the technical stuff.
Aspect-Oriented Development (AOP) is slowly becoming popular because if you want to express your domain correctly, you must avoid to clutter it with technical stuff at all costs. So, that means you have to extract the cross-cutting concern ( Security, Caching, … See AspectJ) out of your code, and apply it globally using Aspects.
Validation can be seen as a cross-cutting concern that is tightly coupled with the domain logic : Validation IS business logic, but it also IS spanned everywhere in the code, at every tier : First you check the constraints using Struts2/Spring MVC built-in mechanism (Annotation, XML..), then you pass it to your business layer which does additional checks, which then passes it to the Data Access Layer (DAOs..), which also has its set of constraints (which can evolve, with time, into something that is not compatible with the constraints checked at the View/Controller level. And this doesn’t take into consideration complex applications where additional batches or gateways are created, where duplicating the validation code is the rule, not the exception.

Currently, if you do not want to duplicate the validation logic, you have to :

Either throw exceptions at the data access level (what do you do for objects that are not persisted ?) and catch these exceptions in the view. Then manually handle the exceptions to display error messages. In other words: bye bye struts2 validation framework, that does everything for you.
Either place the validation logic somewhere in the domain, and “hope” the miscellaneous developers of the various tiers will call the validation logic. If they don’t, then nothing will get validated

What would happen if such a JSR were to be implemented in all major products (Hibernate, Struts2, GWT, whatever else …) :

You would write your domain logic as usual (i.e. using DDD)
You would write your cross-cutting technical concerns as Aspects
You would use a set of standardized Java5 Annotations to specify the validation rules on the Domain Objects, as well as write a set of custom Annotations if you need more than that.
The bottom line: everything would be magically checked at every level of the application : The view technology (struts2, spring mvc) would display nicely formatted error messages without even submitting the form (AJAX…), the data access layer would throw exceptions if the constraints are not fulfilled, and the developers wouldn’t need to care about validation anymore.

The good news is that validation is now believed to belong to the domain thanks to ruby on rails ?), so this kind of design should soon be possible..

Permalink Comments

04.17.07

Acegi and AppFuse 2.0 Captcha

Posted in Uncategorized at 6:26 am by skoobi

Just a few words to give my opinion about this post on Acegi and AppFuse 2.0.

ACEGI

1. If you use composition, your domain objects don’t have to implement the UserDetails interface, so you don’t have to “pollute” them.

1′. Even if you do not use composition, implementing an interface doesn’t mean your domain objects are not POJOs anymore. However, having to inherit some base class makes them not POJO, which is not the case with Acegi.

2. There is no concrete provider, but once again, if you wrap your AccountDao (or whatever JPA/Hibernate Dao ), implementing the provider takes 2 or 3 lines of code….

3. Yes, indeed the documentation is not easy to deal with…

APPFUSE

1. Annotations vs XML debate… I guess it’s a matter of taste.. XML is definitely more powerful, etc, but you don’t generally need this power, and ease of maintenance can be considered as more important that theoretical flexibility…

2. I agree.

Permalink Comments

03.03.07

Re-inventing the wheel vs Integrating many libraries..

Posted in Uncategorized at 1:26 am by skoobi

I happened to read this blog entry about NOT reinventing the wheel. I 100% agree with the author. However, I would like to add something important : Reinventing the wheel is bad, but integrating too much stuff together will necessarily cause headaches about version incompatibilities, subtle problems, etc..

For instance… Let’s say you want to display AJAX-pages that will query the server asynchronously for some stuff, and display the result to the user. One of the best alternatives is DWR, so let’s say you use version 2, because it supports annotations, etc..

Now, you want to create AJAX-validation of your forms. You don’t want to reinvent the wheel, so you use something like Struts2, with the ajax theme. Bad luck ! Struts2 seems to work fine with DWR1, but one will have problems with DWR2… How do you solve the issue ? Patching, patching, patching, if you have the time.

The problem is that this kind of headaches constantly happens whenever you use a few frameworks and libraries, which completly kills the productivity… Another real headache would be the use of Spring 2 + AspectJ + Hibernate to Dependency-inject POJOs… The problem + solution is described on this post…

Another example I came accross would be the incompatibility between some prior ActiveMQ version (before 4.x was released) and Spring 2.0, whereas everything was working fine in 2.0 RC4… The problem came from Xbean 2.6 which was incompatible with Spring 2.0 final….

And I could post hundreds of framework-headaches … I am not saying frameworks and libraries are bad (otherwise, I wouldn’t use them), but they’re not paradise either…

Permalink Comments

Maven2 for Debian ?

Posted in Uncategorized at 1:08 am by skoobi

I came accross this blog entry which is a mini “howto install maven2 under debian”. Thanks for the hint, and thanks to the Debian Java team for working on official Debian packages for maven2.

However, I think we have a deeper problem than just the lack of maven2 package.. Just take a look at the number of jars in Maven2 repository. And this doesn’t take into consideration the jars offered on Java.net repository, or Apache Incubating one.

So, what is the problem exactly ? Well, it is going to be IMPOSSIBLE for Debian to keep up with the crazy and constantly increasing amount of Java jars available. So, instead of trying to re-package Java libraries once again (mainstream developers already have to package them for maven1 and maven2), why not work on some integration between Debian Packages and Maven2 ones ? And when you think a bit about it, Debian has the same problem with PHP PEAR and and Perl CPAN.

Maven2 is a full-blown java package system that expresses dependencies, etc. So, to my opinion, what Debian should do is the following :

Create a notion of a “soft-depencency”. Basically, this would mean that any Package can have hard dependencies (the current deb dependencies), and soft dependencies which could be resolved by a soft-dependency subsystem.
In order to deal with Java, CPAN and PEAR’s case, a soft-dependency could be expressed as prefix:dependency. A soft-dependency manager could register a prefix, and the dependency string would be subsystem-specific. So, for instance, if I need freemarker, the dependency could be maven2:freemarker/freemarker/2.3.8

Now, the question is whether Debian is ready to accept such a shift in its concept ?

Permalink Comments

02.28.07

Dojo : How to animate a ProgressBar

Posted in Web Development at 2:33 am by skoobi

Let’s say you want to display a Dojo ProgressBar, that has a max progressValue of 10 :

width="200" height="20"
hasText="true"
progressValue="7"
maxProgressValue="10" id="testBar" showOnlyIntegers="true" />

Now, you want to animate it so that it progressively reaches its progressValue. Something like the following will be needed :

function animateProgressBar(progressBarName, targetValue anim) {
dojo.event.connect(
anim,
“onAnimate”,
function(e) {
var bar = dojo.widget.byId(progressBarName);
bar.setProgressValue(targetValue * e.x / 100);
}
);
}

dojo.addOnLoad(
function() {

var anim = new dojo.animation.Animation(
new dojo.math.curves.Line([0], [100])
, 2000);

animateProgressBar(
“stressLevelProgressBar”,
7 ,
anim
)

anim.play();
}
);

And it should be working…

Permalink Comments

01.19.07

Xen 3.0 limitations

Posted in Uncategorized at 12:30 am by skoobi

In a recent post, Ian lists the current limitations of Xen 3.0. Nice work ! Definitely Useful, but I would just like to add that there is a trick that I previously described, to circumvent the 3 network interfaces limit.

Permalink Comments

12.16.06

Java, from different viewpoints

Posted in Java at 1:56 am by skoobi

Here is a funny, satirical comment from Daniel Spiewak on Java code produced by different people (student, professor, developer…).

We can probably draw a parallel with the funny quotes about Java I previously cited.

My opinion is that every Java developer is aware that everything he does is far more complex than it should be. However, abstraction is the key foundation of Computer Science, and most people agree that C is a good abstraction over ASM and Java/.Net are good abstractions over C. So, what is the limit of abstraction ? Are frameworks, Design Patterns, Factories and new abstractions all over the place a good thing ?

What is sure is that people who start using frameworks and libraries use even more of them. So, even if it is not a perfect solution, there is something great in that.

Permalink Comments

12.11.06

J2SE 6 : will web development finally be productive thanks to scripting ?

Posted in Java, Web Development at 12:14 pm by skoobi

Sun just announced J2SE 6 and many java bloggers are relaying the information..

Something important for the web development community in this release is the support for scripting languages. In fact, the trend, that has been started with Java Hotswap, is to create tools that allow Web Frameworks to be more productive for developers.

Indeed, developers are tired of the develop / build / deploy cycle, and would prefer to work with the PHP-like develop / reload in browser development cycle. Well, scripting is a step in that direction, and would allow to :

Keep the domain layer as strongly-typed POJOs, that are unit-tested and constantly refactored to keep a good design.
Write the Web Controllers (the C in MVC) in any scripting language (the view being written in any already-existing templating language, such as JSP or Freemarker). This allows rapid development and since the view is hardly reusable anyways, it’s better to throw it away and recreate something from scratch when needed.

Efforts toward that direction have already been started, as relayed by these few blog entries and articles :

So, now the next step is to have universal support for that kind of development, and have better IDE support that will allow refactoring both in the scripted controllers and the view (JSP, Freemarker..). In fact, there is currently no way to make sure nothing is broken besides writing functional (Selenium, Canoo Webtest, HttpUnit…) tests.

Permalink Comments

Meta Patterns

Posted in Methodologies at 11:52 am by skoobi

Jonathan Locke wrote a post about Meta Patterns. I don’t exactly understand what he means by using the “Meta Pattern” expression, but this definitely looks exciting.

In any case, I am curious to see one or two examples of these Meta Patterns to truly understand his thoughts.

Permalink Comments

Building Modern Web Applications.

Posted in Web Development at 9:00 am by skoobi

An interesting post about HTML, CSS is available here. It’s definitely worth reading it.

Permalink Comments

Sami Dalouche

06.02.07

Validation Framework Consolidation : where are we ?

04.17.07

Acegi and AppFuse 2.0 Captcha

03.03.07

Re-inventing the wheel vs Integrating many libraries..

Maven2 for Debian ?

02.28.07

Dojo : How to animate a ProgressBar

01.19.07

Xen 3.0 limitations

12.16.06

Java, from different viewpoints

12.11.06

J2SE 6 : will web development finally be productive thanks to scripting ?

Meta Patterns

Building Modern Web Applications.

Pages

Archives

Categories

Search

Meta