04.17.07
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
03.03.07
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
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
02.28.07
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
01.19.07
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
12.16.06
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
12.11.06
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
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
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
12.10.06
Posted in Java at 11:28 am by skoobi
Glen has a short tutorial on how to perform validation using Spring Valang (which is part of Spring Modules, which provide additional modules to integrate external projects with Spring, like OSCache, etc..) . While it is certainly better practice to choose XML validation instead of writing Validator classes manually, I personally prefer the @Annotations approach that is possible using Webwork / Struts 2.
Not only does it make people more productive by avoiding the need to edit 5 files at the same time (The Java class + the HTML/JSP/Freemarker template is all we should need to edit while creating a web application… Take a look at Tapestry 5 ), but it also shows the validation code at the same place at the code, and thus helps to maintain both.
However, I believe both approaches are not the way to go. We all use the validation features provided by our lovely MVC frameworks because it is handy, but when you think about it, validation should be part of the domain. The domain classes should be intelligent, they should have as much behavior as possible, and validation is one of the thing the domain should provide, in order to maintain integrity. For instance, if a domain layer has 2 User Interfaces (Web, and Swing, let’s say) interacting with it, the validation rules should only be implemented once, in the domain, not twice, because the integrity checks must be centralized.
But the frameworks are not quite there yet :
- Declarative (using annotations, for instance) is built into MVC frameworks and as such, are only tightly integrated to the view, not the domain. So, it requires more efforts to do validation on the domain. (Think of it as Spring MVC or Webwork validation, that automatically returns to the form and repopulates the data in case of an error VS throwing an exception that you have to handle manually)
- Validation defines constraints, and as such, is best expressed declaratively. However, if one wants to check constraints in the domain, it is necessary to either programmatically do it, or use AOP (maybe coupled with Annotations) to do so. However, it is still unclear whether AOP is a good thing to implement domain features. Lots of people tend to think of AOP as a way to implement cross-cutting TECHNICAL concerns, such as security, cache, or transaction demarcation.
Has anyone ever thought about that issue ? Have you implemented (programmatic) domain validation (maybe using Hibernate Validator, which is limited to persisted classes ?) on a real-life project ? What do you think about it ?
Permalink
« Previous entries ·