Eclipse Ganymede 3.4.1 is so far a great environment for Tapestry 5, when paired with the m2eclipse plugin and run-jetty-run launcher (gorgeous live class reloading). A couple of quick notes: 1) Jetty’s slf4j breaks Tapestry’s.This is easily correctable by adding the VM argument to the launch configuration:-Dorg.mortbay.jetty.webapp.parentLoaderPriority=true (wiki article). 2) If using run-jetty-run 1.0.1, know that it will not add the servlet api jar to the classpath.The funny thing is that it does include this jar as a dependency, so it ends up in your maven repository (servlet-api-2.5-6.1.9.jar for example). You can easily “Add external jar” to include it, and be on your way.

Tapestry 5 has seen a lot of updates over the past couple of months. With the addition of the Autocomplete mixin and the Zone component, AJAX is becoming evermore supported and ingrained. When writing AJAX components, using the Autocomplete source as a reference to “how it should be done” is a great thing to do. It’s concise, simple, and shows that AJAX components are on their way to feeling very natural. AJAX event handlers for components behave much the same as they do for normal ones, with the addition of a few new options in the return type. Tapestry makes it easy to respond with JSON objects, in that you can return a JSONObject:

Object onUpdatelist() {
	JSONObject messages = new JSONObject(
		"{users:[{user: 'clewis', firstName: 'Chris'}]}");
	return messages;
}

Nice. However there is another type that would be a very natural return type, JSONArray (not supported as of r638979). I say this because it’s already available in the API, and developers quite often need to return collections of (JSON) objects. So, why not support JSONArray return values? As it turns out, adding this support is not at all difficult, so today I opened a ticket and provided a patch to do just that. Check it out at: https://issues.apache.org/jira/browse/TAPESTRY-2286. The patch updates tapestry’s configuration module, and requires the additional class. With this addition you can now return JSONArrays, without the bother of wrapping your list in a useless object:

Object onUpdatelist() {
	JSONArray messages = new JSONArray("[{user: 'clewis', firstName: 'Chris'}]");
	return messages;
}

Of course even without compiling this into tapestry, you can provide this class and wire it up through your own module.

In an attempt to keep a somewhat vibrant blog about my professional (and nerdy personal) life, I’m writing to share my involvement in a small open-source project: tapestry5-components. This is a component library for the much-anticipated Java web framework, Tapestry 5. Today I officially joined the project and merged my code into the svn repo. This code was from a much smaller component library I started called gc-tapestry-components. I will work on this project in free areas of time (as they arise), and even though my contributions may be small at first, I will strive to keep them significant.

So here’s the deal - thus far in my career I’ve experienced the most satisfaction when developing applications in Java. Specifically, desktop applicaitons in Swing as well as some stand-alone server applications (not web apps/servlets). Of all the gripes and pains of Java, it is a proven, time-tested platform that has gained (and retains) a huge amount of support from 3rd party vendors and enterprise customers alike. Additionally, the developer ecosystem around Java has been on the forefront of software architecture and promoted the wide adoption of language constructs/paradigms such as AOP (No, the Java ecosystem did not invent or discover the concept of design patterns or aspects, but it is one of the most prominent responsible for the mass adoption of such practices over the last decade or so). I personally have learned and continue to learn from this ecosystem. While it has certainly not dictated my growth as a software developer, it has influenced it.

When I started looking in to web programming, a friend of mine turned me on to PHP. At this time I had probably been developing software for 2 years, so I was open to absolutely anything. Being that I didn’t have any push or guidance towards servlets or JSPs (my schooling focused on Swing and applets), I gave it a go. I very much enjoyed learning PHP. It was easy to set up, easy to learn, and fun to code. When I started getting into databases (MySQL of course), I saw the greater potential of PHP and, as many a fledgling developer, thought I was ready for anything with my new tools. I wrote several sites in PHP; raw, frameworkless PHP, and was happy with them. It wasn’t long before I noticed all the issues with this kind of development, none greater than the rigidity of the applicaitons (due to cut-past code, tight coupling, etc). For a year or two I used various tools and frameworks to improve the situation, but I have never been satisfied (my experiences and gripes with such tools, including mojavi, eclipse db, and cakephp, is beyond the scope of this post). On top of this I have developed a general distaste for PHP, and specifically its continued identity crisis as a language.

This laid the foundation for my investigation of J2EE (specifically servlets and JSPs). I had already used some J2EE components (including JDBC), but had yet to tinker with a container or to create even a Hello World servlet. After reading and working through “Core Servlets and Java Server Pages,” I wasn’t convinced this path was any better than my current one, so I didn’t make a transition. In fact it seemed about the same, with the additional overhead of compilation and the general pains of a servlet containers (deployment, reloading, etc). As such I continued down the same frustrating path of PHP, using cakephp as the framework as it at least sped development.

Of course during this time Ruby on Rails had emereged and had begun to take the web world by storm (at least in the tinkering sector) (It was RoR that led me to cakephp, as I was not interested in learning a new language or any of it’s surrounding technologies). I have investigated RoR, and while there are some clearly useful innovations, I’m simply not sold on ActiveRecord or it’s interpretation of MVC (specifically its whole controller/action paradigm).

There are other praises and complaints I have about RoR and related spin-offs, but that’s not what this post is about. What it is about is my repeated attempts to find a sane transition from PHP to Java/J2EE, when much of the world is taking an inverted path (not specifically to PHP, but to lightweight technologies like it or RoR). I believe I have found this path via Apache Tapestry.

Oddly enough, I discovered Tapestry through a PHP framework heavily influenced by it (Prado). I’ll go ahead and state that to date, no framework has made database interaction as quick or easy as RoR, including Tapestry. In fact, Tapestry provides no persistent layer at all, which is admittedly a drawback (note that the upcoming version 5 includes a tapestry-hibernate jar, but I’m not sure what all it does). If you want praises on Tapestry, try google, but what I will say is that getting started with it (version 4.1.2) is pretty simple. Get set up with Eclipse 3.3, Tomcat 5.5, and the Tomcat/Eclipse plugin, throw in the example chapters from EWDT, and you’re on your way. I bought the full book and it was well worth it.

I’ll close with a few statements that will hopefully add some cohesion to this post. Tapestry provides a way for me to impelement web applications on a J2EE stack, without having to invest so much time in digesting the staggeringly large J2EE spec. It also provides a fasinating paradigm to develop applications in, namely it’s component-based approach. An added bonus is the fact that I can share code between web and thick client apps where it makes sense to do so.

Will I invest time in digesting more of the J2EE stack? Most likely, but with Tapestry I can start develping effectively without first spending so much time mucking around in the massive spec that is J2EE.