Thursday, November 30, 2006

New Spring 2.0 namespace


A bit unusual way for configuring the Spring beans seems to be the one Rod Johnson reminds us in this entry of his blog.
Basically a new "p" namespace allows us to use XML attributes instead of nested properties to configure the beans.
What we usually do in this way:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">

<bean id="employee" class="package.Employee">
<property name="company" ref="Company" />
<property name="weeklyHours" value="35" />
</bean>

<bean id="company" class="package.Company" />

</beans>
We could do it like this:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">

<bean id="employee" class="package.Employee"
p:direccion-ref="company"
p:weeklyHours="35" />

<bean id="company" class="package.Company" />

</beans>
A small change that could make our XMLs more compact, although I don't know if more readable.

More examples here.

Monday, November 27, 2006

Sharing URLs


Since is Monday today (I want to complain about something) and since I already read about it, I'd like to support an idea: it would be time that somebody put order to the hell of sharing URLs. What appears normally in blogs () is not sustainable. That each Web to share links have its own form to do it is so last century. I'm not saying to start a JSR for it, but some order would not be a bad idea.

Wednesday, November 22, 2006

Java web frameworks - Which one to choose?


There is something impossible to do these days: choose a Java web framework. Is more a taste question than a technology question. And that's annoying. It makes the competence (read .NET) more easy to adopt. Which one of them must we follow for changes? In my opinion:

  • Shale JavaServer Faces based.
  • Wicket Web modelling... in java.
  • Stripes Classic MVC, but with almost zero configuration.
  • Seam EJB 3.0 based and a little too much JBOSS based.


Update: With the new Seam 1.1 it's possible to use POJOs outside an EJB 5.0 server. Even with Tomcat.

Monday, November 20, 2006

Technologies I would like to work with (I)


One technology which I would like to use to do something productive (read: find a client who pays me to write an application) is JCR (Java Content Repository).
The JSR-170 specifies the way which we would use to communicate with the content repositories. The content repositories or "Content Management Systems" (CMS) like Documentum or Vignette, allows us to save binary or textual information without worrying about where it happens, might be a relational database or XML files.
But every vendor has his own product and his own way of access that information, that's why JSR-170 tries to fix the problem of standardization.
In the open source world, Apache JackRabbit is the reference implementation.
The information is organized as a tree of nodes, with each node having "attributes" or "properties" where to save the data. For example, to save information we do as following (example taken from here):

Session session = JackrabbitPlugin.getSession();
Node rootNode = session.getRootNode();
Node blogEntry = rootNode.addNode("blogEntry");
blogEntry.addMixin("mix:versionable");
blogEntry.setProperty(PROP_TITLE, blogEntryDTO.getTitle());
blogEntry.setProperty(PROP_BLOGCONTENT, blogEntryDTO.getBlogContent());
blogEntry.setProperty(PROP_CREATIONTIME, blogEntryDTO.getCreationTime());
blogEntry.setProperty(PROP_BLOGAUTHOR, blogEntryDTO.getUserName());
session.save();

With this code we would manage to create a node, make it versionable (one of the JSR services), fill it with our information and save it.

You never know, in the near future I may convince somebody to use Jackrabbit. Wish me luck!

Sunday, November 19, 2006

Pico and Spring


PicoContainer, does somebody remember it? It's a components container that uses dependency injection. But it was left in the dust by the hurricane Spring, although it continues having their unconditional followers.
And so unconditional that sometimes it's used (as other technologies) simply because it's "what I know", leaving aside those "I don't know" but gives us many more features to our architecture.
But because nothing in this life is permanent (not even if you use hibernate), and because everything comes (even Java as open source), my friend Ale could finally "refactorize" an application changing Pico with... Spring (the post is in Spanish).