techno.blog("Dion")

As soon as I saw Facelets I was a happy man.

I have always hated:

<h:form>
<h:dataTable value="#{widgetService.widgetDataModel}" var="widget">
<h:column>
<h:commandLink action="#{widgetService.delete}" immediate="true">
<h:outputText value="Delete" />
</h:commandLink>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Name" />
</f:facet>
<h:outputText value="#{widget.name}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Description" />
</f:facet>
<h:outputText value="#{widget.description}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Cost" />
</f:facet>
<h:outputText value="#{widget.cost}"/>
</h:column>
</h:dataTable>
</h:form>

And, moving back to just normal HTML with the odd jsfid attribute, class attribute, etc… felt at home.

If I was writing my own JSF web app, I would jump to use this view instead of the mess.

However, if you were a huge enterprise, and you were sold on “tooling”, then will this play in that world?

NOTE: Taming JSF 1.1 is an interesting article on JSF 1.1.

I realised another reason why I enjoy using Maven the other day.

Let’s start from the beginning….

I often have my build self-contained, so I can run goals/targets to do everything:

% maven/ant dbstart

% maven/ant tomcat-start

% maven/ant redeploy

…

This way all of the properties are setup correctly for the given project. No futzing around making changes.

Over time we find useful, generic (common) goals that we reuse on each project.

I see this happen in two ways in the ant world (not that it has to be like this!):

• Don’t even reuse the targets a lot
• Copy ‘n paste reuse: Oh foo was useful in the last project lets copy it in here

Before you look around there are 4 versions of dbstart in 4 different projects.

Now, what if you are a good boy, and you abstract out the commonality into a seperate build.xml and you just include that, as you can now in ant 1.6?

You end up with scripts such as this jsp precompile that projects use (e.g. AppFuse).

What if fhanik changes his script? Bah, whatever.

Here’s where Maven comes in

I have created plugins such as maven-db-plugin, which abstract all of the database stuff into a nice module. Now I have db:start, db:stop, db:dump, db:populate, etc etc in one nice module.

When I start a new project, I simply declare this dependency and I am done. The variability comes in the various maven properties that I can set in my project (e.g. using mysql, the jdbc driver, the user/pass, etc). Maven 2 has even nice auto-plugin installation which makes this even cleaner!

The nice thing about this is that development on making the db plugin is seperate from the project. If I release a new version of the plugin that fixes a bug, or adds a feature, I have the option to use that version in any project with a simple dependency change.

I end up with a lot less dead code, and my build related files stay nice and small, as all of the commonality is elsewhere.

This may sound like a very simple thing, but I sure appreciate it!

One of the most common complaints with Ruby, is the fact that i18n isn’t Just There.

Seems especially strange for a language written by a Japanese Mormon doesn’t it? :)

Well, there are a few alternatives out there, including the new ri18n.

Also, isn’t Ruby 2.0 going to be unicode from the get go?

In the “what can we learn from Rails and bring to our environment” camp, we see Lisp on Lines.

Now you can go crazy with the Meta Object Protocol and Lisp away!

Your entire web app is just a bit of ( ( ( ( ) ) ) ) )

I had an interesting experience when I happened to adblock a little TOO liberally on akamai.com content.

I quickly found out the sites that use akamai, as their images, and other items such as CSS and JavaScript was lost.

Sometimes it was kinda random what was coming from akamai, and what was coming from the server itself….. (united.com was one example).

A project that I am joining is using MyFaces implementation of JSF, and Sitemesh for decoration (I am a big fan of Sitemesh).

There is a known problem, where you can not put JSF code (you know, and all that rewriting of html ;)) in the decorator.

However, we were running into a problem where even if the decorated page had JSF tags in it the app would freak out and you would get no HTML response.

The JSF code was running, as the log file was showing us that.

We dropped in the JSR RI and it all worked fine, so I thought it may be a MyFaces bug. However, MyFaces works in AppFuse and the like.

This is where a debugger kicked in, where TDD wouldn’t really help as much.

After walking the stack I saw that the MyFaces extensions filter was freaking it all out. When I took that out of the filter chain all worked well.

The problem wasn’t actually the extensions filter itself though, the problem was the order of the filters defined via filter-mapping’s in the web.xml.

Since Sitemesh is doing magic on the entire chain you should put the filter-mapping at the beginning, as then the container will run it first… and it will then chain.doFilter()…. which will do its thing and when it unravels, Sitemesh will be the last to finish up.

Gotta love debugging fluff like this!

I love The Office. Ricky Gervais has his new sitcom, Extras booting up tonite on BBC 2.

He has some teasers:

• here
• here
• here

Now I need to work out how to watch it in the states. I am sure some kind soul may be it up on bittorrent? Not that I would use that…

When you plug together a web framework, and Spring, you end up making choices on how to do this (unless you use Spring MVC).

Considering DRY, you really don’t want to have to:

a) Setup the model as a bean in Spring
b) Also setup the same bean (with the same name maybe for convention) in the web framework

Seeing all of this configuration can be irksome, so we thought that this would be a perfect use of namespaces which could allow us to go from:

<managed-bean>
<managed-bean-name>newWidget</managed-bean-name>
<managed-bean-class>de.mindmatters.faces.spring.SpringBeanScope</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>

<bean id=”newWidget” class=”model.Widget” singleton=”false”/>

To:

<bean id=”newWidget” class=”model.Widget” singleton=”false” jsf:scope=”request”/>

Google Moon is here. It may seem a little pointless, but now I can work out:

• a) Where to buy advertising on the moon
• b) Where to look for crater side housing for when we start to live there
• c) Seeing Wisconsin Cheese at full zoom

:)

In honor of the first manned Moon landing, which took place on July 20, 1969, we

David Geary did something interesting at his Rails talk at the Denver JUG.

He took someone from the audience, and made them the code monkey.

This was trying to show how easy and intuitive it is to get something simple running in Rails (even from someone who has never touched Ruby etc).

I imagined seeing David giving one of his JavaServer Faces demos and doing the same thing. Picture half-way through:

David: “Bob, now make the code grab the ‘foo’ bean in JSF”

Bob: “Er?”

David: “Come on! FacesContext.getCurrentInstance().getApplication().getVariableResolver().resolveVariable(FacesContext.getCurrentInstance(), variableName);! Simple!”