Raible Designs

The AppFuse Generator

I found the AppFuse Generator project in my comments last night. Richard So seems to have created a nice code-generation tool for AppFuse. It looks like it can create/modify all the files you need to CRUD a database table. I took a brief look at the code and it's all based on Velocity templates, so you should be able to easily tweak things.

This tool does seem to generate the DAOs/Managers - which can lead to more code to maintain. It would be nice if it could be modified to be similar to AppGen where there's a "detailed" version (that generates everything) and a "default" version (which only generates the web tier classes). The default version could use the generic "dao" and "manager" beans. I wonder if this tool supports running/installing the same table more than once? This currently doesn't work too well with AppGen, but shouldn't be too hard to fix.

In reality, I'm pumped that Richard has created this, as well as a project to back it up. I especially like that he's going to try and create an Eclipse Plug-in as part of this project. Nice work Richard!

Tapestry by Example with Erik Hatcher

It's Saturday morning and I plan on learning more about Tapestry this morning. There's pretty light attendence in the room. Too bad - I bet if it was a JSF talk, the room would be packed. In this talk, we're actually going to build a real application on-the-fly.

Why another web framework?

• HTML should be HTML
• JavaScript Embraced
• Reusable components
• Free developer from dealing with plumbing
  • Request/Response
  • Session/Application Scope
  • URL Mappings (nice, but leads to ugly URLs)
• Event handler driven
• Asset handling
• Line-precise error reporting

Erik says its one of the few frameworks that embraces JavaScript so much. I dig this b/c I think JavaScript is important for web development. Look at what the GMail guys have done with JavaScript. It'd be wicked cool to have this sort of thing open-sourced so we could all create GMail-type interfaces.

Dirty Laundry

• Heavy Duty - can be overkill for small/simple app
• Potentially steep learning curve. More of an un-learning curve. The Servlet API isn't in your face - so all that knowledge is useless.
• Not widely accepted - managers haven't heard of it
• Some awkward conventions (i.e. abstract classes)
  • and some non-intuitive necessary tricks
• Unit testing tough - do you unit test your swing app's listener methods?
  • Tapestry Test Assist should solve this problem
  • Howard's caught the TDD bug, so this should get better
• Lousy URLs - there's a patch on the wiki to fix this
  • Tough to do hit/stat tracking
  J2EE declarative security
• Example applications
  • Workbench and VLib included with Tapestry
  • Better Pet Shop

Workbench Demo - DatePicker component does do i18n (very cool!). Client-side validation does one-field at a time, like WebWork does. I prefer the "all messages in one pop-up" approach that Commons Validator has. Pallete component looks very cool - you can move and re-order items from a multi-select on the left to a multi-select on the right. Chart component looks pretty cool - you can generate graphs very easily. Unfortunately, it's not part of Tapestry, but you can see how to do it in the Workbench app. If you want to see an online version of the workbench, I have it setup on my server.

Repositories for components: Tacos, Tassel, T-Deli and a few mentioned on the wiki.

To bring a component to life, you simply add a "jwcid" to an HTML tag. You can specify initial values for page properties using <property-specification initial-value=""> tag in your template's .page file. The value is implicitly an OGNL expression, and you can define lists using "{'value1', 'value2', 'value3'}". This is great for prototyping before you have a backend or even a page class. To remove elements in a page, specify jwcid="$remove$" on an HTML element and it'll be removed at render time. The restriction is you can't have Tapestry components inside a $remove$ component.

If you don't want to use abstract methods (and hence classes) in your page class, you can use getProperty()/setProperty() methods. However, the recommended way is to use abstract methods.

Templates - two different types. You can put the @component stuff directly into your page - or you can use jwcid's and refer to a name that's defined as a <component> in your page-specification XML file. The Border component can be used to do page decoration like SiteMesh. You can use the Shell component to declare stylesheets/scripts on a per-page basis. This is something I do a fair amount, so it's nice to see it's built into Tapestry.

Internationalization - Resource bundles are component specific (one .properties per page). In a .page, you use <message-binding>. In a template (.html), you use attribute="message:key" or <span key="">. The "key" attribute can't be used on any ol' HTML element, only on the <span> tag. In .java, you use getMessage() and format(). You can also define a custom message source (i.e. read messages from a database). I'm impressed with how easy it is to do i18n in Tapestry. It's also cool that i18n is built-in for templates. Just include a locale extension on your page and it'll be rendered for users with that locale. For example, home_fr.html will show up for users with the French Locale.

Engine - gets all requests. Visit class - POJO that acts as like an HttpSession. You can configure it in the .application file. You can talk to your "Visit" class in a template using "ognl:visit". To call methods on it, just use "ognl:visit.method". Majority of services originate in the Engine. Generally override createXXX methods. Engines can be pooled or created on a per-session basis.

If you override the createXXX methods in Engine, you change the behavior for:

• message source
• global and visit
• property configuration
• template and component sources

contrib:Table - to override use <tr jwcid="columnColumnValue@Block"> - where "column" is the name of the column. Using this, you can easily put links and such into a table cell. Built-in TableModel can be used to talk directly to a JDBC DataSource. The TableModel is smart in that it only brings back the rows it needs to display. Add an exclamation point to the beginning of a column name to turn off sorting for that column. i18n is built-in for headers - the name of the column is simply looked up as a key in the page's .properties file.

Exception handling - Bail out by throwing an ApplicationRuntimeException. This tosses you to the default exception page, which you can override and "pretty up".

Validation - it's robust, but it can only validate <input type="text">. Erik thinks that Tapestry's validation framework could be much simpler and easier to use.

Dynamic Templates - can implement a IDelegateSourceTemplate and pull templates from a database or content-management system. To register your new TemplateDelegate, you can just register an <extension> in the .application file and point it to your class.

Page Lifecycle - initialize(), PageRenderListener(), PageValidateListener(), PageDetachListener(). Can use an ExternalCallback and ICallback to set properties on one page from another. Callbacks look very cool and there's a lot of discussions about them on the mailing list. The VLib app has a fair amount of callback examples.

This was definitely a good Tapestry session - thanks Erik.

Facets of Ruby by Dave Thomas

You can learn Ruby in 4 hours. This talks isn't to learn Ruby, but rather to show facets of Ruby. Ruby has made programming fun again for Dave. It's also made him more productive.

Languages and tools make a difference

Ruby has variables, methods, but no types in methods. When Dave first started using Ruby, he had a strong typing background - and was terrified of Ruby's un-typed feature. He first thought Ruby was a toy language for hobbyists because of the lack of typing. Now, many years later, he really likes the lack of typing and hardly even has bugs relating to typing. He notes that with Java we store most of our data in Collections - and those are all Objects - so Java is essentially un-typed as well. How often do you get ClassCastExceptions? The rooms concensus is not not a whole lot. To make up for the lack of typing, Ruby developers tend to write a lot more unit tests.

ActiveRecord - Ruby O/R Mapping Library

Ruby on Rails - not a single line of XML. Uses intelligent defaults and allows you to override them. The following creates a wrapper around the "ranks" table.

class Rank < ActiveRecord::Base
end

The original author of RoR thinks that every database table should be plural, so singular class names map to plural table names. It's even smart enough to change Person to a "people" database table. Apparently it has a bunch of the singular-to-plural mappings for the English language built-in. The key to Rails is clever defaulting - allow you to write a lot less code, but override if you really need to.

ActiveRecord has many lifecyle hooks (17) that you can override. For example, before_save, before_destroy, validate. For example

def before_save
  self.when_added ||= Time.now
end

I wonder if Rails has any support for transactions and specifying propagation behavior on transactions? I asked Dave this question and it sounds like ActiveRecord has a rich support for transactions - and even wraps the "save" method with a transaction by default.

"Ruby is pretty damn good at web applications"

Simple CGI is a common choice. FastCGI and mod_ruby in Apache are other common choices. There are also a number of different web frameworks for Ruby:

1. Roll-your-own
2. Templating systems
   1. erb
   2. Amarita
   3. RDoc templates
3. Iowa - similar to WebObjects
4. Ruby on Rails

Ruby on Rails - MVC Framework

Contoller - one method per view. Setup context (a.k.a. the model) for views. Views contain "rhtml" - HTML with embedded Ruby. Lots of helper functions. Can access model data (context) setup by Controller. The name of the method in the Controller determines the name of the view file. A "select" method will dispatch to a "select.rhtml" file. The method name to call in a Controller is determined by the URI - for example, /ranks/view calls the "view" method in the RanksController class. Pretty slick! I like the idea of smart defaults - IMO this should be used a lot more in webapps. I'd love to get away from mapping URLs in Struts, Spring and WebWork.

Rails has built-in support for configurable URLs - so you can change query strings to more slash-type URLs. What about things like client-side validation, success messages and sortable/pageable tables? Do those exist in Rails? I asked Dave and he said said they have good support for success messages with a "flash" concept and the post-to-redirect problem is almost non-existant because most controller invocations are redirects. Client-side validation and sortable/pageable tables don't exist in Rails.

Rails has Needles - and IoC framework similar to Pico. However, there's a fair amount of traffic on the mailing list and a lot of Ruby developers think they just don't need IoC. Dave's suggestion is to use Class Injection.

The largest Ruby application is probably Daves - 55,000 lines or code, couple hundred thousand users. There are entire companies who write all all their applications in Ruby. The founder of Rails wrote it so he could write Basecamp - which is only 4500 lines of code.

Good stuff Dave - and definitely a nice overview of Rails. Will I be digging in an using Rails anytime soon? Not this year, I'm going to have some fun with Tapestry and JSF first. Maybe next year.

[DJUG] Web Services and Geronimo

We're finally getting started at 6:25 and we were supposed to start at 5:50. Good ol' projector issues. This time it was a bent pin.

J2EE 1.4 introduced the first web services component type (SE) and augments EJB specification (2.1) to expose SLSBs as a web service endpoint.

Writing J2EE 1.4 web services ("endpoints")

Two J2EE components to implement a web service:

• JSE (JAX-RPC Service Endpoint). New component, new deployment descriptor. Looks like a servlet, acts like a servlet. Run's in a web container like a servlet. Isn't a servlet.
• SLSB. Exposed as web service via deployment descriptors.

JSE is easier because it's (mostly) POJO based. EJB might be preferred if you already have EJBs or you need transaction management. However, the SOAP client calling the EJB web service does not participate in the transaction (at least the spec does not define it).

"Mandatory" transaction attribute not allowed in EJB endpoints because SOAP client can't propagate transaction.

JSEs are similar to servlets:

• Instances run in the web container
• follow servlet lifecycle
• Must have a public no-arg constructor
• Can add servlet filters just like you do normally

Steps to writing a web service JSE:

    1. Write remote interface (the service endpoint interface) - must extend java.rmi.Remote and throw RemoteException
    2. Write implementation class
    3. WSDL Document
    4. Deployment Descriptors (web.xml and web-services.xml)
    5. Create WAR File

J2EE 5 will allow you to turn any POJO into a web service - no interface needed. Apache Axis can be used to generate the WSDL for you with Ant. You map the implementation class as a servlet, with a servlet-mapping and everything. The difference b/w JSE's and servlets is you can only map one JSE to one URL.

Writing web service clients. Client model is defined by the JAX-PRC 1.1 spec. You can write web service clients using three JAX-RPC techniques:

1. Generated Stub - Easiest. Done at development time. JAX-RPC is invisible to your code. Stub classes hide it. Runtime implementation will be tied to a vendors JAR because vendor tool will generate class based on WSDL.

2. Dynamic Proxy - Most Portable. Done at runtime. Your code asks JAX-RPC factory to create stub at runtime that implements SEI (Service Endpoint Interface).

3. Dynamic Invocation Interface (DII) - No Stub Necessary. Useful for tools - e.g. dynamically retrieve WSDL then show user on a GUI what services are available and allow user to select what should be called. Client sets URL, methods to invoke and required parameters.

Future of J2EE web services. JAX-RPC 2.0 (JSR 224) in the works. The goals of JAX-RPC 2.0 are several:

• Make writing WS simpler by using metadata and annotations.
• If you write an endpoint interface, your implementation class won't have to implement it.
• Remove requirement to define a remote object.
• Better support for document-centric web services.
• Integration with JAXB.

Tom's presentation was quite good for his situation. There was a *ton* of technical issues and he had to show his presentation on Chris Huston's Powerbook. This meant no demos since he had JBoss 4.0 and everything else setup on his Windows laptop. After flailing about for the last hour - he admits its time to buy a Mac.

Apache Geronimo

1. Apache Software License
2. Uses other BSD-derived, open source projects
3. Initial manifestation as a J2EE 1.4 application server 4. J2EE 1.4 certified (in-progress)

Started a year ago in September. The main motivator for Geronimo was there was no BSD-derived license for an open-source application server. The GPL license requires you to contribute code back if you customize a product. BSD allows you to do anything, you just have to give credit back to the originator. Sounds like the proper license for AppFuse to me.

The heart of Geronimo (the kernel) knows nothing about J2EE. It's designed to do just about anything you want it to do - it's just a configuration away. Jakarta project at Apache makes up a huge portion of ASF projects. Many of these projects are pieces of the J2EE puzzle. However, there wasn't any glue to hold it all together. Geronimo re-uses a *lot* of existing (best of breed) open source projects.

Geronimo still doesn't support Tomcat. The main reason is because 3 of the Jetty committers are part of the Geronimo team. Jetty was the first component every deployed in Geronimo. According to Bruce, someone is working on integrating Tomcat right now. You'd think this would be pretty easy and only take a couple days to do. Maybe I'm wrong.

Geronimo is NOT another lightweight container, web framework, or AOP framework.

It IS designed for long running servers. Its designed to tolerate partial component failures. System oriented services.

Geronimo Kernel - Fundamental Core

• Small memory consumption ~ 150KB code
• Component Registration
• Component Configuration
• Integrated Repository
• Lifecycle Control
• Dependency Manager

Now Bruce is going on about Maven and how it works. ZZZzzzzz. Maven schmaven. He does have a good point though - it works great for building and managing multiple projects and their dependencies. Geronimo has 30 sub projects - yow.

A lot of concepts and architecture in Geronimo is derived from Maven. Hmmm, I wonder if that means it's slow.

What are GBeans? They're a J2EE managed component (a JMX MBean), which are basically simple objects plus some metadata. Used to bridge JSR-77 lifecycle requirements. GBean wrappers allow just about anything to be plugged into be plugged into Geronimo. Implement the GBeanLifecyle interface: doStart(), doStop(), and doFail().

Bruce is now showing us the DerbySystemGBean that's used to stop and start GBean w/in Geronimo. Bruce has a lot of good things to say about Derby and thinks it's a much better database than both MySQL and PostgreSQL. That's a pretty strong statement, but since he met with Derby's architect last week, I tend to believe him. I'm assuming since I got AppFuse working with DB2 that using it with Derby would be pretty easy too.

Bruce says there's supposed to be a Geronimo release this week. I thought they were supposed to be done with Geronimo by this year's ApacheCon?

Now we're looking at an XML file that's a GBean configuration file. It looks like Spring is going to get some competition for long class names. And if you thought Spring's XML was verbose - Geronimo puts it to shame! I'm not saying this is a bad thing - it's just an observation.

GBean Archive - A JAR file that contains persisted GBean instances, GBean metadata. The Java classes in the GBean can reside in the JAR or be dependencies in a central repository.

GBean Descriptor - dependencies and configuration are defined in XML.

Repository: Structured collection of JARs. Designed to work in conjunction with Maven (pluggable implementation). Every JAR has a unique group and artifact id. Default repository is local file system, others allow auto-download.

Observation: Bruce's presentation is interesting - he seems to be targeting folks that want to dig into Geronimo and customize it. I think most developers just want to use it and would be more interested in seeing a demo of deploying an app on Geronimo, rather than how to integrate Derby or Jetty into the server. If it's so easy to plugin a component, why hasn't Tomcat been integrated? Maybe it's just me, I want to see it run and deploy apps to it - that's about all I want to do. In most cases, I shouldn't need to customize it. It's nice to know that it's an option though.

Basic Configuration Builder: Deployers are J2EE specific (JSR-88). If you have standards-compliant deployment descriptors - your application should deploy on Geronimo. Rather than calling them deployers, Geronimo uses "Builders". The Builders /deployers create configuration objects containing GBeans. Most complex Builder is J2EE deployer. It implements a JSR-88 deployment specification and accepts JARs, WARs, EARs, and RARs. You can also add in a deployment plan in XML. From this, a Geronimo Configuration ARchive (.car) is created. The nice things about these builder is you can do deploy-time optimizations, before the application is started.

Everything above the System Services and Kernel is hot swappable. You can remove the J2EE Configuration and replace it with something else like Pico or Spring. This means that you'll be able to swap out servlet containers w/o shutting down the server. That's pretty damn cool. If the system services and kernel are stable, and no JVM dumps occur - this means that your Geronimo server could be running forever. Sounds awesome.

High-availability (clustering, etc.) has not been built into Geronimo yet. This is primarily because this is not part of the J2EE spec. Developers are focusing on gaining 1.4 compliance, then they'll start looking at the fancy features.

Wow - good presentation Bruce. I feel like I know more about Geronimo than I ever wanted to know.

As I was getting ready to post the above transcript, I noticed that Geronimo 1.0 M3 was released. According to Bruce's presentation, this is the last release before 1.0. Nice work gents.

Can you base a web framework on another web framework?

It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:

3.5 Service Provisioning APIs

Inversion of Control (IoC) containers (the techniques are also referred to as Dependency Injection) are becoming a popular mechanism for assembling the required services and logic of an application. If Struts included such a framework, it would provide a solid basis for building maintainable apps, as well as allowing the framework to configure itself using the same capabilities.

Rather than building such a container ourselves, we should seek to incorporate an existing one that is license-compatible and which can be integrated into the JSF managed beans facilities (so that value binding and method binding expressions can leverage the facilities of this container transparently). From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions.

3.6 Authentication and Authorization APIs

In order to support reasonably complete solutions for applications that wish to provide their own authentication and authorization services (as well as interact with container managed security), we need APIs available for performing user registration, implementing "remember me" features, and represent the results via a wrapped request (so that apps depending on getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work). Using JDK 1.4 as a base platform would allow us to integrate mechanisms like JAAS. Other alternatives include plugins like SecurityFilter.

I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.

The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.

If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.

Comparing Web Frameworks Presentation

Since Kris let the cat out of the bag, I might as well give you the link to my comparing web frameworks presentation (PDF, 280KB). I also created a page on the Equinox site for this presentation and related materials. In addition to the presentation, this page also has links to the various framework implementation demos. Here they are for your convenience:

• Spring
• JSF
• Struts
• Tapestry
• WebWork

Kris notes that I would still choose Struts. I think it should be noted that I would only choose it in combination with AppFuse (which generates ActionForms). Same goes for Spring and WebWork. I've added interceptors and convenience methods that simply make developing with these frameworks faster and easier. I would've chosen WebWork for my current project, but I'd like to see better client-side validation. Spring needs better tag libraries.

I think the choice of what framework to use is a very personal thing. I think the "best" framework for one person might be very different for someone else. For me, I typically do short-term projects with clients - get them up and running with an application, and then head off to the next project. It makes sense for me to create applications that use a popular framework like Struts that they can easily find developers to maintain it. However, the one thing I'm starting to find is that as long as I use AppFuse - there's good documentation on how to do things. So I've already written the "how to develop and extend this app" for future developers of a client's application. This will (hopefully) open the door for me to use any web framework that AppFuse supports.

I think WebWork rocks, but it's similar to JSF in that it doesn't come with everything your need. The good news is it's easy to write interceptors, but IMO there's a few that should be part of the framework. After working with Tapestry and JSF, I can see how component-based frameworks will be the wave of the future. I think as you develop more and more components, the code you write becomes less and less. It's funny that this is one of the goals of AppFuse - incorporate a bunch of tips and tricks for various frameworks to make development easier. By adding support for Tapestry and JSF, hopefully AppFuse will someday become a repository of useful components. Documentation is good - code is better.

I'd probably be more enthusiastic about Tapestry and JSF if I knew more about them. I still have a lot to learn. I've bought the books (Tapestry in Action and Core JSF), I just haven't had time to read them. I think after incorporating these frameworks in AppFuse (hopefully this year), I'll get a better feel for them and how they make development faster and more efficient. My major problem with JSF is that it's being written for the tools vendors and not for the developers. Make it easy for everyone, not just folks that want to use their hammer-like IDE to develop webapps. The major problem I have with the JSF Tools is 1) none of them are free and 2) most of them are tied to a proprietary app server.

[ANN] Equinox 1.1 Released

In preparation for my talk on comparing web frameworks, I've made a bunch of enhancements to Equinox. I changed the default web framework to be Spring and added a very simple "CRUD users" feature. While it's basic, it shows how to do validation, success messages, and a sortable list with the following frameworks: Spring, JSF, Struts, WebWork and Tapestry. I even added a "birthday" field to demonstrate date-handling. I dig the built-in popup calendars that ship with JSF and Tapestry.

• Download
• Demo

Oh yeah, I also added a hack (from James Violette) to make the Display Tag work with JSF. Code says it best. I plan on writing a detailed how-to as part of the Display Tag's documentation. Suggestions for a cleaner hack are welcome.

In other display tag news, here's another way to do static headers.

AppFuse a top 10 java.net project?

I don't know if it's really a top 10 project, but it gets lots of hits, accesses and mail traffic. Nice! I'm willing to bet it's the cool logo that's the source of its popularity.

BTW, I'm giving a talk on AppFuse at Denver's No Fluff Just Stuff in two weeks. If I can finish up the "appgen" tool by then, the talk could be a lot more fun as the demo would be short and sweet. I doubt it'll happen though. I'm knee deep in creating a version of AppFuse Light that showcases how to use Spring with Hibernate and your choice of web framework: Struts, Spring, WebWork, Tapestry or JSF. I hope to release it sometime this weekend or early next week. Next week (and likely the week after), I have to write Chapter 10 of Spring Live. That leaves almost no time for creating the next cool tool. Who knows though - it might be easier than I think - especially since Lance submitted a good start.

Trails - like Rails, but with Tapestry, Spring and Hibernate

I've been thinking about Rails ever since I wrote a post about it on Monday. The main reason is because of Dion's comment:

Matt - You should follow the lead and do a video of setting up a simple app using AppFuse.

This might sounds like a good idea, but if I did it right now in AppFuse's current state, it'd be a disaster. The reason? Because you have to manually create a whole bunch of classes to do CRUD on a database table. Here's a list of new classes needed for adding a new "person" table.

• model.Person
• dao.PersonDAOTest
• dao.PersonDAO
• dao.hibernate.PersonDAOHibernate
• service.PersonManagerTest
• service.PersonManager
• service.impl.PersonManagerImpl
• webapp.action.PersonActionTest
• webapp.action.PersonAction
• web/pages/personList.jsp
• web/pages/personForm.jsp

The last two JSPs can be generated, but that's still a buttload of classes (9) just to CRUD (and test!) a database table. Not too mention all the files you need to edit for Spring and i18n.

• dao/hibernate/applicationContext-hibernate.xml
• service/applicationContext-service.xml
• test/web/web-tests.xml
• web/WEB-INF/classes/ApplicationResources_en.properties
• web/WEB-INF/menu-config.xml

Result: to CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long! While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized. Of course, if I was focused on fast and efficient, I could do this all with 1 JSP and JSTL's SQL tags. Everyone would slap my hand for not following patterns, but I'm willing to bet it'd work just as well and be just as fast. But I digress.

There have been a fair amount of requests (and some patches submitted) to generate and modify all of the files listed above. For the most part, I've frowned upon adding such a feature because I think if folks can run "ant generate -Dmodel=Person" - they'll end up with a whole bunch of code that they know nothing about. Sure there's the tutorials, but folks will quit reading those. Instead, they'll create a whole slew of POJOs (maybe even using Middlegen) and run "ant generate" on all 50 of them. Poof - now they've got 550 new files to maintain. Talk about a maintenance nightmare. Even worse - a support nightmare for me.

Nevertheless, if I wanted to create a cool video for AppFuse, I'd spend a few days writing this code-generation engine. Then I could show how you could create the data, service and web layer (including UI) in a matter of seconds. It'd be cool and folks would dig it. I'm still considering it, but I'm also leary of the resulting support fiasco. Maybe I could just say "use at your own risk".

A while back, I saw Erik Hatcher suggest a better solution than code-generation. I can't remember what he called it, but it was something like "meta-data dynamic rendering". The idea is that your application reads the metadata of a table (or POJO) and renders the appropriate UI for it. I loved the idea as soon as I heard it. I've always wanted a way to dynamically render the UI rather than writing HTML. Of course, I still want the ability to edit the templates and HTML since I fancy that sort of stuff. I don't like writing HTML for each row in a form, but I do like tweaking the HTML and CSS to look good.

Earlier this week, I saw the concept in action with Rails and its demo. IMO, something like Rails would never fly in Java because it appears to be tightly coupled to the database and only MySQL, PostgreSQL, and SQLite are supported. The Java community always seems to pride itself on database abstraction, partly due to JDBC and its ability to connect to anything that has a JDBC Driver. Ruby will probably catch up someday, but right now it appears to be looking for something like JDBC.

Then along comes Trails, which made me smile earlier today when I first read about it on the tapestry-dev mailing list.

I've been working on a project called Trails that uses Tapestry quite heavily and I thought it time to start soliciting feedback. Trails is a domain driven development framework that uses Tapestry, Spring, and Hibernate. Trails is very much in it's infancy, but the current version is functional and should give people a rough idea where I am heading. It's my first real forray into Tapesty and I have really found Tapestry a joy to work with.

Trails is very much like Rails, except that it doesn't talk directly to a database table. Instead, it talks to your domain objects that you mark up with XDoclet/Hibernate tags. To test it out, I dropped a User.java file into the org.trails.demo package, marked it up with XDoclet and deployed. It didn't work at first because the .hbm.xml files are explicitly listed in Spring's applicationContext.xml. I changed the "sessionFactory" bean to use the following and wammo - success! I could list and CRUD the table that my User object was mapped to.

  <property name="mappingDirectoryLocations">
    <list>
      <value>classpath:</value>
    </list>
  </property>

Trails is very cool, and I'd love to incorporate it into AppFuse or Equinox. Does an LGPL license allow me to do this? The one problem I can see with adding it is that it's specific to Tapestry and Hibernate, which doesn't always suite folks. I think developers might be willing to change because this solution will vastly improve their development productivity, but who knows. I think the best solution would be to offer this option in AppFuse/Equinox, but also offer the current manual and code-generation options. The holy grail would be the ability to plug in iBATIS or JDO instead of Hibernate. In addition, using Struts, Spring, WebWork or JSF instead of Tapestry would have folks clammering to use this stuff.

Mad props to David Heinemeier Hansson and Chris Nelson - you guys are developing awesome software.

Rails - the MVC Framework for Ruby

When I first saw the quick setup for Rails video, I dismissed it as a something simple that wasn't that cool. Thanks to Dion's post, I decided to watch it again. Then I realized why it looked so simple the first time - the video kept looping and all I saw was the Apache setup part - I didn't see the whole video. After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp. Then again, Ruby probably doesn't pay the bills nearly as well. The upside is it looks like it would actually run fast on OS X instead of the dog-slow Ant/Tomcat/Eclipse/IDEA combination.

Hopefully I'll get to learn more about Rails at Denver's upcoming No Fluff Just Stuff. It looks like Dave has added it to his repertoire. I wonder if Rails has support for using the Copeland IoC container?