techno.blog("Dion")

I went to see Erik Hatcher talk about Tapestry at the local JUG last night.

It was a good talk, as Erik does a good job and explaining what is good and bad at a developers level (no foofy high level marketing-speak :)

If you have used Tapestry, it is painful to look at JavaServer Faces applications. I had a really interesting conversation with Erik about how a framework is needed ON TOP of JSF, to give you a nice way to work.

How will we get this framework?

• Tapestry Server Faces: In theory, since JSF has a lot of extension points, a Tapestry layer could be placed on top of the JSF event handling model. It would look like Tapestry. Feel like Tapestry, but would be running in JSF (I don’t know what Tapestry would gain from doing all of this work though)
• A Faces Impl: Something like MyFaces can come a long and write a layer on top of the JSF crud. They are already doing a good job on making some things easier… and this would be taking it to the next level
• Struts: Some would argue that Struts as it exists is @deprecated (as Erik puts it). It could evolve to become glue on top of the base JSF framework
• JSF itself: They could make the spec and the RI decent. Shocking I know.
• Some New Thing: Of course, some bright spark can come along and out-do everyone :)

I wonder if this approach could work. Could we have a usable layer on top of JSF? Would JSF tools be able to work with this world too? Or will we always be stuck in a lowest common denominator?

As every vendor comes out, they have their own set of widgets, so you end up working on “Oracle JSF” versus “JSF” anyway. I know, in theory you could use Oracle components on some other server…. but in reality: it is about the tools, and sometimes that doesn’t work that great.

In this vein, it was good to see the JSF Component Metadata Proposal from Oracle.

I really hope that there will be a JSF world where my HTML isn’t hidden away under ugly taglibs. This is the web. We work with HTML. Let my designers see it!

Mike Henderson is on a roll with his entries on Tapestry, and custom hooks.

Less Configuration – Enhanced Tapestry Component Resolution, Part Two, Part Three.

I like to be able to organize files into groups with folders and I also don’t like to do too much configuration file maintenance. Tapestry will find components in the /WEB-INF directory in my WAR without configuration but with many pages and components in an application it becomes unwieldy. Tapestry allows me to add these components to my specification, specifying the path, relative to the /WEB-INF folder, and t-deli.com provides an ant-task to automate the maintenance of these component declarations. What if I could structure my pages and components into any directory structure I want and not have worry about maintaining the application specification file, even with an automated tool? I could add components while testing without a restart. Since servlet containers can explode a deployed WAR file into a directory structure this method would even work in a deployed Tapestry application.

Fortunately, Tapestry has a number of extension points which can be used to extend various framework behaviors. One of these is the ISpecificationResolverDelegate interface.

I wonder if any of this will change with 3.1…. especially with the enhanced HiveMind stuff.

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!

Merrick has a nicely thought out critique at Lightweight Containers in comparison to EJB 3.

His basic premise is that EJB 3 fills the gap of the lightweight containers. Although I think it is a great step forward, I think there are a few areas which worry me:

What are we specifying?

I would personally love the expert group to be able to step back and think about what EJB is all about. Where is the “E”, and what should be spec’d?

In my humble opinion, I think that the EJB spec should be a pretty lean one, that acts like the J2EE spec… in that it offers the programming model + integration hooks into other specs. The other specs are basically out there to define the cross-cutting enterprise services, and could later have AOP info.

The obvious example is persistence. Get a new spec for that if you really can’t stomach talking to JDO people. But get it external, and have it for EVERYONE.

There are also many other examples. Security, worker threads, blah blah.

Backwards compatibility requirements

I understand backwards compatibility is good. However, I think it is OK to make some things optional. Having all of the EJB 2.x and below baggage is painful for some people (e.g. Spring) and keeps them out of the loop. Make it optional, and if you ARE backwards compatible you can get a shiny checkbox. Then, if a company gives a monkeys they can get an implementation that has the shiny star.

Inclusion

In some of the open source projects such as Spring, there is an air of inclusion. What do you want to do for persistence? JDO? Hibernate? iBATIS? We will hook in and help you out with all of them.

You don’t feel that same way with the EJB vendors. The feeling is more like “Oh man, they want to hook us into their damn EJB CMP engine that we can’t bloody swap out as the PersistenceManager STILL isn’t pluggable after all these years”.

Come on guys, let’s play nice. You can still compete on features / QoS / etc.

So, although I am excited about EJB 3…. I want more :)

You know the feeling when you open up some code from a fellow programmer, and it says a lot about them?

Their code style speaks to you as does the style of an essay does.

My latest experience is looking at various Groovy code snippets. There have been two extremes that I have come across:

I like my Java, just with a twist

These folks are happy in Java land, and the code looks just like it. There are just a few things differing. Maybe the odd ‘;’ is left off of the statements. Here and there variables aren’t staticly typed. But, mainly, it looks like Java

I want to be different

Some of the guys who have really bitten into Groovy really try hard to have their code NOT look anything like Java. Everything is groovy-fied to the extreme.

This reminds me of some days when I was deep in the Perl community. Since the language gives you 55 ways to do something, you see even more contrasting styles. In that environment you could find the hacker, the one liner, the I have a Comp Sci degree so I code correctly!, the obfuscator, and more.

Fun :)

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 had a chat with James at JavaOne, and we discussed the whole open source Java topic.

My biggest frustration about all of the talk in the industry has been that it didn’t seem like anyone was giving any actually information on what THEY considered an open source Java to mean.

Why do you want open source Java?
What don’t you like about Java as it stands?
What do you want to open source?
What license?
Who has access / power?

James has thought about the various scenarios that we currently have, in which the current Java model gets in the way. He then has cut to the chase on what would need to happen to help these scenarios out, and the solution ISN’T to open source all of the Java source code, the JVM, etc etc.

He basically wants to create an open source project (JRT) which is the rt.jar. Note that this isn’t a Java brand thing, and would mean that the poor GNU Classpath guys could focus on other things :)

Check it out. What do you think? Why Sun should open source Java and how – a new proposal (not open source Java but JRT)