Well, my foray into Ruby territory has led to a complete re-write of this PHP based site (this marks the first post under the new publishing system.) As I've posted here before, I'm quite impressed with the Rails framework and it's ability to lessen the development of web applications down to implementing what the application actually does, instead of wasting time implementing system-level details. These details are not trivial - mapping relational database tables to objects and creating an MVC environment for your code to operate in is a significant undertaking, as most developers would agree (If you disagree, I'd love to chat.)
But wait! Rails isn't the first framework to offer these conveniences. What about Struts, Hibernate, blah, blah, blah. I've used them. I even like them. But seriously, configuring these frameworks to work with one another can be mind numbing. Let's not even go into the initial steps involving the inclusion of 8,369 jar files into your project - can you say 'ClassNotFoundException'? The fact that Rails includes an ORM implementation AND an MVC implementation, both under the SAME project, is something very special. Let's look at some pitfalls that Rails makes a thing of the past.
Java Beans
Plain vanilla Java beans are a great way to store, access, and transfer data in the object domain. This is not rocket science and has been well known for a long time. The problem is that everyone wants their own slice of the pie. Both Hibernate and Struts want to use their own set of java beans, even though they both describe exactly the same data. What's even more annoying is that Struts requires its java beans to ride the short bus to school: they can only store String objects (Okay, and Boolean, but that doesn't really help.) This means that your data needs to be continually shuffled between the Struts beans, your business objects, and the beans used in your persistence layer.
Many developers, including myself, feel that multiple sets of java beans are a redundant waste of time, code, and money. This is the topic of many flame wars, and can be compared to the Eagles playing the Giants. The bottom line is that I don't want to write any java beans. getThis(), setThat(), how about forgetItAllAndUseRails().
XML
I've been writing J2EE applications long enough that editing XML configuration files has become second nature to me. If someone is touting that their jar file will make your life easier, you can expect that it needs at least one XML file. This isn't exactly a bad idea, its just that it may be an unnecessary step and can lead to lots of headaches during maintenance.
Okay, now its time for another flame war: Rails circumvents XML files by having the developer follow naming conventions. Yes, this means that you must name things in certain ways if you want them to work properly. This rates right up there with Emacs vs. Vi. I can't count the number of times I've gotten into an argument over the naming of different things:
- "We shouldn't use underscores in the table and column names, your waisting a character!"
- This table should be plural since the cardinality of the relationship is one to many!"
- That variable name is descriptive, but its way too long!"
It turns out that there are no absolute rules when it comes to naming these types of things, and I might not agree with all of the naming conventions chosen for Rails, but at the end of the day I really don't care. Those conventions make sense to some people (very smart people actually,) and I can live with them if it means that I don't have to waste any more time editing XML files. I think in most cases (not all cases,) XML is an application band-aid, especially when the XML is being used for configuration. The only problem is that the application never heals, so the band-aid is never removed.
Conclusions
I'm not convinced 100% that Rails will take over the world. But I am convinced that ORM and MVC should be available in a single framework (Not to mention the other great features of Rails like the testing module.)
<action path = "convert"
type = "com.joestelmach.actions.StrutsToRubyConverter"
input = "struts.jsp">
<forward name="rubyConversionSuccess" path="theJoysOfRuby.jsp" >
</action>