techno.blog("Dion")

David Geary is a friendly chap who is on the No Fluff Just Stuff Symposium tour.

He has started a blog, which has been talking about JSF (he is on the Expert Group, has the book [Core JavaServer Faces], etc).

His latest post discusses the fact that JSF can render some things on the client side.

He also had a reply to Matt’s thoughts on working with JSF

It is fun to watch Matt go through his application, porting it to every web framework out there (reminds me of when Kris was doing this to the Wafer web log software).

Now he gets into JSF.

Of all the MVC Frameworks I’ve developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) – JSF was by far the worst. And it’s not the implementations that are the problem, it’s the spec itself (as far as I can tell). Plain and simple, it does not simplify web development.

I spent 3 days developing a simple JSF app – most of it which I had done in the first day. The last 2 days have been spent migrating to MyFaces and trying to find clean ways to do things. My perspective on JSF after this experience? Run away. Run far, far away. All of the above mentioned frameworks are MUCH superior to this technology. Let’s get on with the things I learned.

Painful. I have run into the same problems. It seems that the only reason to use JSF is: “Well, it is a standard, a bunch of big companies are behind it, and the tools will come which make it simple”.

Does that give you warm fuzzies? :)

These days my choice of framework is normally:

• Event driven: I want a large event driven system, that makes a good use of components, and lets me develop in Java, and my designers design in HTML…. Tapestry (not JSF)
• Simple Request/Response: I want something simple, which sits on top of the request/response system….WebWork 2 (not Struts)

This assumes that there are no politics, that I am not working with a team of experts in another framework, etc etc…

I hope JSF 2.0 thinks about bringing in other good framework guys this time (e.g. Howard, the Swinglet guys etc).

Let’s make WEB stuff easy. How often are you going to deploy the same application magically in different ways. It just isn’t that simple!

Erik Hatcher finally had some time to grok AOP and AspectJ. He got quickly up to speed (as he normally does) and saw a use for it right away.

The one feature that has bothered me about Tapestry is its difference with what happens when validation fails compared to Struts. When validation fails, the listener method is still called in Tapestry, and this requires a bit of code to handle it *in every single listener method*. While I’m still on the fence on whether Tapestry should itself avoid calling a form listener method when validation fails, in the apps I build it is always the case. AspectJ came to my rescue. I created this aspect…

public aspect ValidationAspect {
void around(BasePage page) : execution(void
Home+.listener(IRequestCycle)) && this(page) {
ValidationDelegate delegate = (ValidationDelegate) page.getBeans().getBean("delegate");
System.out.println("aspected: " + delegate);

if (!delegate.getHasErrors()) {
proceed(page);
}
}
}

That piece of code looks for anything that implements Home base class / interface (Home+).

It would be nice to make this generic for anyone using Tapestry as Erik has said, so that it would only be called on org.apache.tapestry.form.Form listeners (via a cflow()).

Nicely done Erik :)

Here we have another one in the “get me away from angle brackets” category.

Kris Thompson pointed to the Nice clean, dynamic MVC framework: NanoWeb.

NanoWeb is a simple and powerful dynamic MVC framework based on Java servlet technology,Groovy and NanoContainer. NanoWeb borrows many ideas from WebWork and Struts, most importantly the concepts of actions and views. Its main difference from these frameworks is that it is 100% dynamic and requires no configuration beyond mapping of to servlets in web.xml

Pelle Braendgaard wrote a nice introduction to NanoWeb, in which he walks you through a simple application.

I liked his quote after writing the Groovy action:

I am no Groovy expert. As a matter of fact this was my first attempt at groovy and I have no idea what I

The folks at Sandcast Software have kindly started a set of Tapestry Tutorials.

The first one done, that you can download now, walks over a simple CRUD app in Tapestry, and then it gets more and more fun from there:

Enhancing our application using Hibernate (pt. 2) – In this tutorial we will walk through integrating Hibernate with our existing CRUD listing.
Available 08/13/04

Enhancing our application using Spring (pt. 3) – In this tutorial we will walk through integrating the Spring framework with Hibernate and other beans that we have created with our existing application.

Enhancing our application using HiveMind (pt. 4) – In this tutorial we will walk through the same steps that we did with the Spring framework to highlight the differences between Spring and HiveMind.

Enhancing our listing with a paging component (pt. 5) – In this tutorial we again turn our eye towards the interface by implementing a paging component that allows the user to more easily navigate multiple results.

Enhancing our listing with a search component powered by Lucene (pt. 6) – In this tutorial we add a Lucene-based search component to our listing page to aid in user navigation.

Enhancing our listing with a sorting component using contrib:table (pt. 7) – In this tutorial we investigate one of the contributed components contrib.:table and how we can use it to sort our listing on specific columns.

Enhancing our listing with hot-links (alphabetical jump-links) (pt. 8) – In this tutorial we investigate how to implement alphabetical jump-links for our listing. Basically this would allow users to click on a letter and go to a page with only those items beginning with that letter to be shown. We will be using Lucene and a custom component to achieve this.

Creating a new listing using the contrib:tree component (pt. 9) – In this tutorial we investigate another type of listing, the tree listing and how we can achieve it using the contrib:tree component.

Thanks!

I am a big fan of Tapestry. One of the only items left on my list of “this bugs me” was the fact that I didn’t have the control over the URLs that I want.

I want URLs to say something, and detest any gobble-de-gook. I think it DOES make a difference.

Howard has promised that this feature will be in 3.1, and it looks like someone has done the heavy lifting for him ;)

Identitytheft911.com has written code that allows them to map URLs, so if you go to:

http://www.identitytheft911.com/resolution/crisisresolution.htm

it gets mapped into the normal Tapestry URL:

http://www.identitytheft911.com/app?service=page/crisisresolution

The explanation:

There are 2 parts: generating and interpreting.

To generate the urls, I use custom PageLink and ExternalLink components
that utilize a custom ILink implementation that generate the urls using
the following pattern:

/ .htm
The path-to-page-specification is taken from my application specification.

e.g.

specification-path="resolution/CrisisResolution.page"/>
path-to-page-specification = resolution/
page-name = crisisresolution
generated url = /resolution/crisisresolution.htm

Using lower case page names was done at the insistence of my site
developer…

To interpret the urls, I have a custom Tapestry servlet that is mapped
to the url pattern *.htm.
In my service() method, if the url query string contains “sp” (i.e.
Tapestry.PARAMETERS_QUERY_PARAMETER_NAME), then I generate a Tapestry
external link, if not I generate a page link.

Great stuff!

After playing with Groovy and WebWork 2, Michael Henderson has written about his Tapestry-Groovy integration.

It will be really great to be able to use Groovy as the config language (instead of XML, and even maybe instead of the SDL in HiveMind), as well as for the Components and Pages themselves. Since Tapestry is such a nice OO/component view of an application, Groovy fits in nicely. Hell, we could use Groovy instead of OGNL too (if it made sense!)

My Adigio co-founder Christian Parker is having fun with Groovy. We went to a talk by Rod Cope at the Boulder JUG last week, and it got us thinking about where Groovy can fit into a web application that CP is working on.

Groovy as Actions. Groovy as the View. Groovy as the XML configuration. Groovy everywhere!

In this entry Christian talks about the work he did integrating Groovy with WebWork 2. It will be really cool when you can put it in debug mode, which would enable you to tweak the Groovy action and hit reload to test. No more compile/build step!

There has been a lot of buzz about JavaServer Faces. Since its release, people seem to love it, or hate it. A lot of the hatred revolves around the JSP tags that you have to work with. Hans Bergsten shows us the flaws, and then shows us, what he thinks, is a better way.

This kind of article is great. I totally agree with Hans that the JSP approach is really clunky, and have mentioned some of these reasons in the past. Just look at a fairly complicated JSF page and you will wince. Show that to a designer and they will cry.

The component model itself isn’t that bad, and Hans gets to that. JSF also really needed to lift the bar and give us some awesome components right off of the bat, rather than leaving them to the community/third parties. If they could have wowed us with amazing controls, then more people would be jumping for it IMO.

JSF: Promising
Tapestry: Today

Improving JSF by Dumping JSP

TSS Discussion on the article

I have been having fun with Tapestry for the last couple of days. It really is a breath of fresh air compared to some of the Other frameworks.

Although request-based frameworks allow you to get the job done… and there are some good ones out there (WebWork 2 is great)… I am really enjoying a more component/event-driven approach.

A long long time ago, in a galaxy far far away I remember writing a web templating system. One of the major goals was that the HTML “templates” should be WYZYWYG/browser preview friendly. This was very much needed based on the way that we built websites, and how the designers were in the process.

Ever since then I have shed a tear or two when I see lots of evil markup which makes a system non-web designer friendly. JavaServer Faces unfortunately seems to take the cake on this one with its <f:use_faces> …. and just check out a table based on facets!

As soon as you start to work with components, this holy grail becomes hard to find… however I really like that Tapestry tries hard at this goal.

There are definitely cons to this approach. You could argue that having a conditional look like:

<span jwcid=”@Conditional” condition=”ognl:isFun”>foo</span>

isn’t as easy to view as:

#if ( isFun )
bar
#endif

However, being able to have real HTML makes it worthwhile, and after a few minutes you can get it.

Having this HTML approach is just one thing that I like. What I really like is how the I can’t put code in my view, and how the low level servlet stuff is just really hidden nicely. This is great stuff. Thanks Howard.