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.

Cake is a decent framework. In fact I have very little gripes about it all around - plently of little picky things, but only one that really bugs me: cake’s model implementation.

Cake’s finders inherited by all models (find, findAll, etc) return 3d hashes, keyed at the top by the model class name, the middle with field names (model properties), and the bottom with the field values. This is a nice simple way of handling things, and does indeed work well for smaller applications. I’ve worked on several that attest to its usefulness (http://rosaloves.com for one).

Now for the rant: This Does Not Scale. Because we must deal in arrays instead of objects, we lose two very important OOP abilities - encapsulation and polymorphism. Our result models are not objects, so they are incapable of such notions. We have no typing, no method signatures, and therefore no effective interface. All entities must then have intimate knowledge of how our model is composed. There’s no point in getting into why this is bad - it has been documented over and over since the inception of OOP.

Why arrays? I am not involved in Cake’s development (though I hope to be an accepted contributor soon), so I can’t speak for them. In comparison with Ruby on Rails, I will wager a guess. Firstly, Rails’ finders are basically static methods (static as in Java), called class methods in Ruby, if I’m not mistaken. These methods only exist once in memory, as opposed to instance methods, which exsist per object instance. Static/class methods cannot operate on instance data (at least in Java, where ‘this’ is invalid). I’d wager that Rails’ finders/savers, as well as all relational mapping metadata, are static class members. This way model instances don’t carry (duplicate) this data per instance.
Php 4 can’t do this, not cleanly or naturally anyway, so Cake uses model instances singularly, probably to emulate the feel of executing finds in Rails. If Cake returned model instances (which it should), each instance would carry copies of the relational mapping data. If Cake exploited php 5, this metadata could be static and therefore shared between all instances of the model class. This could be achieved in a few ways in php 4, but it would be messy to say the least.

I’m only guessing that this is one of the reasons Cake does what it does. I’ll continue with a later post going further on thsi topic, as well as get into a project I’ve started on CakeForge called Object Model (http://cakeforge.org/projects/object-model/).