Raible Designs

[NFJS Denver] Howard Lewis Ship and Creating Tapestry Components

Tapestry - "we try to make the simplest approach the correct approach." I haven't been blogging much of this session b/c I'm just sitting back and soaking it up. It's a good session and Howard is a good speaker. I'm learning a lot about Tapestry and it's philosophy about web development. I especially like the line-precise error reporting - it's something that all frameworks need to do better.

Tapestry looks very cool. You basically write an abstract Java class that has abstract methods for properties you define in an XML file. Tapestry them implements this class and its abstract methods. The class that Howard wrote to handle a login form is very simple - it's only about 7 lines long - and 4 of those are abstract methods! The HTML form is cool too - not much of the HTML has changed since it was bare-bones HTML. He's merely added some a few "jcwid" and "listener" attributes to some of the elements.

Tapestry is a large system of subsystems, all implemented behind interfaces. It ships with its default behavior (i.e. page/template pooling), but you can (supposedly) easily change this behavior or implement custom classes. Internationalization is a first-class citizen in Tapestry - no surprise here since it is in most MVC frameworks. Tapestry 3.1 will embed Hivemind at its core and will provide much easier integration with tools like Hibernate and Spring.

Tapestry's "Validation Subsystem" looks very rich - providing both client side and server side validation. It uses Field decorations to highlight both labels and fields when validation fails. By default, it promotes using CSS to change colors, backgrounds, etc. There are a couple of Helper Beans for validation: the Validation Delegate and the Validator. It's pretty neat that you can bind a label to a field in XML. Since HTML already allows binding <label>'s to form elements - you'd think that Tapestry could harness this by parsing the template. I suppose it's just easier to require the XML binding - then you don't have to worry about the user writing invalid HTML.

Howard is trying something new in this presentation - real-time coding. I use this in my presentations and it works pretty good. He's having some serious issues b/c he can't mirror his laptop's monitor with the projector. This obviously makes it difficult to code since the slide show is his monitor. I try to use pre-canned code (i.e. IDEA Live Templates) so there's less chance of fat fingering things. I also use a Mac - on which mirroring works great.

The "Page" object is pretty cool in that it contains a bunch of lifecyle methods you can override. Most frameworks don't have lifecycle methods. I guess Spring's SimpleFormController does with onSubmit, onBind. Lifecycle methods are a Good Thing IMO. The formSubmit() method is always called, regardless of validation errors. Therefore, you have to get the IValidationDelegate and check if it has errors before continuing. I wonder what the logic behind this is? Most frameworks seem to support automagical validation - with no further work required by the programmer. I guess it's kinda cool b/c you can continue with validation errors if you want to. Choice is always a good thing.

Howard just showed us a client-side validation example. The wicked cool thing is that the client-side script is configured in a .page file rather than in the HTML template. Most frameworks I've seen (that support client-side validation) require you put something into your template. This was a good talk, I'm definitely interested in Tapestry and excited to start learning it in the next couple of months.

[NFJS Denver] David Geary and Advanced JSF

David is going to cover some JSF advanced topics: data table, tiles integration, custom components and validators. I was talking with Rick Hightower last night. He mentioned that he's been doing a fair amount of work with JSF lately and really likes it. He actually said he thinks he can develop a webapp faster with JSF than he can with Struts. He also said that JSF ships with a lot of what you need - and a lot of the JSF books seem to cover how to add new stuff (custom components and validators) you don't need. This is to say that the books tend to cover the features of JSF, rather than how to develop successful projects with JSF. I said I thought it'd be nice if there were some JSF books by folks who'd used it to deliver applications. More of a "here's what you need to know" kindof manual. I think that's what JSF needs.

The <h:dataTable> in JSF is pretty much the same as the <c:forEach> tag in JSTL. An interesting note on the JSF expression language - it starts with a # instead of a $. For example:

<h:dataTable value='#{tableData.names}' var='name'>
...
</h:dataTable>

The major difference between JSF and JSTL's expression language is that JSF EL can access managed beans. The JSP 2.0, JSTL and JSF expert groups are going to work together to try and synch up their expression languages. Personally, I don't see why the JSF folks didn't just use JSTL and simply include managed beans in the lookup logic. Here's a wierd one - if you use any "template text", i.e. in a dataTable - you have to wrap the text with <f:verbatim>text</f:verbatim>. David says this is one of the embarrasing things about JSF. He hopes it'll be fixed in the next version.

The <h:dataTable> looks very similar to the DisplayTag. Sweet - that's one less thing I'll have to worry about when creating a JSF app. I've said it before and I'll say it again - my two favorite tag libraries are the DisplayTag and Struts Menu. As I'm learning new frameworks, one of my major goals is to reproduce the same functionality I enjoy in my Struts+JSP apps. It's been pretty simple so far with Spring and WebWork, since both support JSP. However, it might get a bit tricky with Tapestry and JSF. I'm sure it'll be possible (and hopefully easier) to reproduce this functionality, it's just a big unknown at this time.

"Form" beans in JSF are not like form beans in Struts. It's really just a class that doesn't extend anything and has action handler methods. An interesting point - the actionListener's value (which is really a class.methodName) can be any class in any scope OR it can be a managed bean. How about some code:

public class Form { 
    public void changeLocale(ActionEvent e) { 
        FacesContext context = FacesContext.getCurrentInstance(); 
        Map requestParams = context.getExternalContext(). 
                            getRequestParameterMap(); 
        String locale = (String) requestParams.get("locale"); 
        if ("english".equals(locale)) { 
            context.getViewRoot().setLocale(Locale.UK); 
        } else if ("german".equals(locale)) { 
            context.getViewRoot().setLocale(Locale.GERMANY); 
        } 
    } 
}

The major reason behind the FacesContext is to support Portlets. So rather than using a ServletContext or PortletContext, the FacesContext provides a level of abstraction. The underlying theme of JSF: To be as flexible as possible. This is to say that there are many ways to do things with JSF. I often think it's better to have less choices when learning a technology, but once you're versed in it - choices are great. I guess I just wanna know the best way to do things, not all the options. Actions are for business logic, ActionListeners are for UI logic. ActionListeners are always fired before Actions - in the event that you have an actionListener and an action defined for the same component. Listeners and Actions are really just methods on a class and they can actually both be in the same class. JSF is starting to appeal to me. This session has been one of the fastest so far - there's only 20 minutes left and it feels like it's flown by.

JSF ships with converters for dates and currencies out-of-the-box - cool! Now David is explaining about a custom CreditCard converter. This is what Rick was talking about last night. Why do we need to know this stuff? Would a normal talk on another MVC Framework talk about converters and validation? I bet not. I think it's a good topic - maybe something that other frameworks should cover more visibly. The Converter interface has two methods: Object getAsObject() and String getAsString(). The Validator interface has one method: void validate(FacesContext context, UIComponent c). I just asked David about using Commons Validator instead of JSF's core validator. He said, "Yes, it's possible." Sweet! You can use Commons Validator with Struts, JSF and Spring! Now if we could only get support for it in WebWork and Tapestry - then I'd eliminate my need to learn another validation engine.

Now David is talking about using Tiles with JSF. It looks as simple as using the <tiles:insert> tag to insert dynamic content into an <f:subview>. Any time you insert a tiles component, you need to wrap it in an <f:subview> tag. That was short - we're done talking about Tiles. I had some questions - i.e. can you refer to a definition directly from an action or in the action's navigation definition? Oh well, onto custom components and renderers. Custom components and renderers seems to me to be something that should be left out of these types of presentations. Sure, it's cool they're possible - but who's using them? Have you needed them in a real-world JSF application? I only want to know the things I need to know to develop a real-world JSF webapp. Sorry, I forgot - there aren't any real-world webapps written with JSF. If I'm wrong - send me a link. ;-)

This presentation was good - it inspires me to learn some more about JSF. Maybe there'll be some projects in my next gig that require JSF - that would be wicked cool. After all, the best way to learn this stuff is to get paid to do it. If nothing else, I'll get to learn it later this year when I write AppFuse's web layer in JSF.

Recovering

Yesterday I got inspired to get myself out of this funk and go to a local VW Show with the fam. I woke up, took a shower and almost passed out. Probably from standing up more than I'm used to - or the dizziness that constantly surrounds me. After resting awhile and popping a pain killer, we jumped in the car and headed out to Golden. The show was awesome and I saw lots of nice buses and bugs - and even joined the Colorado VW Bus Club. I felt dizzy most of the time, still no appetite - but nevertheless - I was active. It felt great. I spent the rest of the day on the couch with passing fevers.

This morning I woke up determined to go to work. After waking up, I headed into the living room with breakfast. Julie took my temperature and said it was around 101. So I popped some Tylenol and decided to rest for an hour before heading into the office. After resting and taking a cold shower - I got dressed and headed into the office (40 minutes North). I was sweating so bad - I guess from the fever breaking - that I had to take a towel with me for the trip. Anyway, to make a long story longer - I made it to the office and worked most of the day w/o any issues. I also managed to submit my two weeks notice to my current client. He wasn't surprised and said he'd been expecting it sooner or later.

So where am I off to? EJB Solutions - the inventors of Out-of-the-Box - for a 3-month contract. I grew to love Out-of-the-Box after my last Linux install and I'm very excited about working on a product I love. Here's the best part. I asked them what I might be working on for the first month. Here is their response:

...updating sample applications, especially those using Hibernate, XDoclet, and Struts to bring them up to date with the latest versions, recommended idioms, beef them up, etc.

Sounds like fun, eh? I'm pumped and can't wait to start in two weeks! Another intriguing factor for me was I can ride my bike into the office (when I do go in) and it's shorts and t-shirts all summer. Denver summers + riding bike to work + shorts and t-shirts allowed at work = a very happy Java Developer. The contract is scheduled to end when Raible #2 is born (Labor Day Weekend - September 3rd). After that, I'm taking a month off to be a good Dad and hopefully I'll be able to find another contract starting in October.

As far as my illness and contributing to open source, I've come to realize that my body is capable of amazing feats. Sleeping 2-3 hours a night, coding 20-some hours per day. But it's no life for me. However, it was a life I was planning on living all the way until Spring Live is finished in late June (right before JavaOne). I'd still like to finish the book by then, but it's going to take a serious shift in priorities. Which basically means, drop everything and work on the book.

I'll probably still try to get AppFuse 1.5 documented and released by the end of the month - but then I really need to virtually abandon all my open source contributions. It's just the only way I can see to pump out 150 pages of Spring stuff in 1 week off + a bunch of late nights. I still plan on blogging a lot b/c when I'm busy I tend to blog more. I think AppFuse could use the lack-of-development for awhile - it wouldn't hurt to stabilize the code-base over the summer.

Mapping buttons to methods

In AppFuse, I use Struts' LookupDispatchAction to map submit buttons to methods in my Actions. It's caused quite a headache for i18n, but Jaap provided a workaround and now everything works fine. However, as I did the Spring MVC implementation this weekend, I didn't have to do any complicated "button value -> method name" mapping. Part of it was because I didn't need to, but also because I discovered that you can easily just check if the button's name was passed in. Explaining this with code is probably easier. Let's say you have three buttons on a page:

The HTML code for the above buttons is:

<input type="submit" name="save" value="Save" />
<input type="submit" name="delete" value="Delete" />
<input type="submit" name="cancel" value="Cancel" />

Using the name as your key, you can easily check in your Action/Controller/etc. to see which button was clicked:

if (request.getParameter("save") != null) { 
    // do something
}

The nice thing about this is that it doesn't care what value you put on your button - just what you name it. It seems like all frameworks should use something like this, rather than a single parameter name (i.e. "method") that requires JavaScript on a button to change the method invoked. About a month ago, Rick Hightower mentioned that he uses a ButtonNameDispatcher for Struts. Rick, if you're reading this - I'm ready for that bad boy!

Populate your drop-downs with listeners and allow for refreshing

Most webapps have drop-downs (a.k.a. pick lists) that users select from when filling in forms. Spring has a nice referenceData method on its Controllers that you can use to populate these, but I prefer a different way. In AppFuse, I populate these using a ServletContextListener. However, one of the problems with using this is that your drop-downs won't get refreshed unless you have admins screens or a way to reload the attributes set in the listener.

In short, I think it's a good idea to load drop-down options in a listener and also have an action or servlet to refresh these options. For examples, see StartupListener.java and ReloadAction.java. Got a better way? I'm interested...

Logout your users automatically after their session times out

One of the common issues I see in webapps is a user leaves their computer, their session times out, and when they come back to do something - the app throws errors b/c their session is null. There are several easy ways to fix this. If you use Container Managed Authentication, the user will likely be prompted to do login and can continue as before. If you're using a slick Remember Me feature (like AppFuse has), the user won't even notice. However, you might not have these options available to you. For those circumstances, I recommend you put a meta-refresh in your app to automatically show the uses a timeout message when their session expires. It's as simple as the following:

<meta http-equiv="Refresh" 
  content="${pageContext.session.maxInactiveInterval}; url=timeout.jsp"/>

I used JSP 2.0's EL in this example for simplification. If you're using a JSP 1.2 container - you'll have to wrap that expression with a <c:out> tag.

How does your MVC framework handle duplicate posts?

One of the problems that you'll often see in webapps is that when a record is added - hitting refresh on the browser will cause a 2nd record to be added. This is because the "Save" action usually does a forward, rather than a redirect, and the full post is re-created. I'm curious to know how other MVC Frameworks handle this issue, particularly Spring, WebWork, Tapestry and JSF. In Struts, it's pretty simple to solve. When the form is first displayed, you'll likely go through an Action. In AppFuse, this would be something like UserAction.edit(). In the edit method, you add a saveToken() call to put a token into the session:

Then in the save() method, you can check for a duplicate post using the isTokenValid() method:

How does your Java MVC framework handle this? Do you have to programmatically handle it like Struts - or is it built-in to the framework to handle it auto-magically?

My Review of Java Studio Creator (a.k.a. Rave)

I attended a Rave Demo at Sun in Broomfield today. The meeting actually had two parts - the first hour was a marketing schpeel about Sun's Enterprise Java System and the second hour was a demo of Java Studio Creator. The first hour was boring and very marketing esque - they did have an interesting price point though - $100 per employee. This is small business friendly, which is nice to see.

The Rave (a.k.a. Java Studio Creator) Demo was when things got good. Here's my notes from Dan Robert's presentation, followed by my impressions and comments. Dan is the Product Manager for JSC and was seemed to be very in tune with the tools marketing (i.e. all the good stuff from Intellij and Eclipse - and how JBuilder sucks).

What is it?

• New Java Development Tools initiative
  • For the corporate developers who write code, but don't understand all of the complexity of J2EE and just need to get their job done.
• A full fledged Java IDE
  • Visual Design Tools, 2-way editing, Editor, Debugger, Repository Management, and Project Management
  • Cool new Look and Feel
• Complementary to NetBeans and Java Studio
  • Even Enterprise developers can use it for Rapid Prototyping
  • Use Java Studio or any other tool to add persistence layers (heh, this is b/c they think that persistence can only be EJBs ;-))

What does it do?

• Quickly builds web applications that solve time-critical, real world problems
  • Complete web application creation for departments, workgroups and businesses of all sizes
  • Focus on easy to understand, event driven coding model
  • Simplifies access to existing infrastructure
  • All Java-standards based servers, all databases, all Web services, all desktops
  • Their main goal is to do web applications well, they'll catch up with the rest later

Standards-based solution for all developers

• A development solution based on 100% Java standards
• Delivers "Write Once, Run Anywhere"^TM benefits: portable apps, portable developer skillsets
• Quickly solves time-critical app development needs
  • Drag and Drop, rapid visual access to databasess and web services
  • consistent UI look/feel/behavior across all apps

Visual features to speed development

• Palette for widgets, custom graphics, code clips, etc...
• Query Editor

Simplified Access to Existing infrastructure

• Use any JDBC Compliant Database (3.0)
  • Drag in and automatically create DB connections to data-aware components
• Web Service Consumption
  • Easily pull in existing web services from Enterprise wide solutions or business partners

Java Studio Creator Roadmap

• Hammerhead:
  • 2-tier dynamic content web applications based on JSP and JSF with Page Flow design tools
  • Releases: Early Access Spring 04 (today!), FCS Summer 04 (at JavaOne)
• Thresher:
  • Minor Update Release
  • Focuses on Ease of Development and Stability
• Mako
  • Extended Client Support

Download today from http://www.sun.com/jscreator. OS X version will be available shortly after the release (JavaOne).

After the PowerPoint, Dan started into the Demo. The first thing I saw that was cool was that when he clicked on the "Run" button, it actually deploys the app and opens the browser to run it. What you see in the browser looks very similar to what you see in the IDE. The IDE looks very simple. My current client went with me and he remarked that it "looks a lot like Eclipse."

The IDE has lots of palettes, and the UI essentially looks very clean. The pallets can be docked just like in IDEA - which I like. It looks a lot more like a native Windows application than it does like Swing. Here are the palettes it has:

• Server Navigator
  • Data Sources
  • Web Services
  • Deployment Servers Palette
• User Defined
  • JSF Standard Components
  • JSF Validators / Converters
• Property Sheet
• Project Navigator

Dan then dragged a drop down component and a table component onto the page. Secondly, he added a stylesheet and it visually changed the background and fonts on the page. I asked him if there was an imbedded browser. He said they took a look at using Mozilla, but it was too much and apparently one of the "real smart" engineers wrote the embedded browser component from scratch. Dan said it was the same guy who wrote the demo from scratch in 2 minutes at JavaOne last year. The thing I found very cool was that the HTML that is written into the JSP is XHTML - none of this Netscape 4.x support. Fuck Netscape 4.x - I'm glad Sun had the foresight to drop support for it.

After adding the stylesheet, Dan used the Data Sources navigator to grab a table and drag it to the drop-down. Then he did the same for another table and the data grid. Using the Visual SQL Query Builder (which looks a lot like M$ Access) he linked two tables and added a new column from a 2nd table to the grid. He then showed us that JSC has pretty good support for 2-way editing. Edit the code, the visual representation changes. Edit the visual, the code changes. This seems to be a big problem with WYSIWIG editors, especially when it comes to dynamic webapps. It appears that they've done a pretty good job to solve this.

Next he showed us some cool features of the components. For the table, there is an "enable paging" checkbox - and for the drop-down, you can right-click and select "auto-submit on change." He then set a couple of converter types on the drop-down and had to hand-code the event handler for the drop-down. Two lines of very simple code and he was done. The code was simple enough that you could have guessed the syntax. Code completion popped up nicely as well. Apparently the JSF coding style is that each page (JSP) is backed by a Bean that contains different event handlers. The code looked pretty simple and all the data was retrieved via RowSets.

Bill Dudney was there and asked about testing tools (i.e. Cactus or JUnit). Dan's response was that these are usually used by more advanced Java developers and there's talk of it, but nothing has been done yet. Now he pulls up a very cool page navigation creator which he uses to drag and drop buttons and links to point to different pages. Then someone asked about cost - and here's what makes it great. Under $300. They also hope to have lots of add on components for JSF by JavaOne. Unfortunately, there's no tooling for building JSF components in Java Studio Creator. For more information checkout http://developers.sun.com/jscreator.

The main reason I really like Java Studio Creator was that you literally never had to see any JSF code - and you get all of the features I like to use in webapps. Furthermore, I've been training a couple of guys all week on JSPs and using JSTL's SQL tags to do CRUD on a database table. While it's simple stuff, since they've never done web development before, it's a bit advanced. I'm sure their eyes will glaze over tomorrow when I start showing them how to write JUnit Tests, DAOs and how to use Hibernate to CRUD an object. They'll probably fall asleep by the time I show them how to wire the DAOs to Hibernate using Spring. When they saw this demo today - there eyes lit up and they got inspired to do their projects again. It looks easy for them now. All they need is a JDBC 3.0 driver for DB2 and they should be able to rapidly develop webapps with Java Studio Creator. I don't blame them for wanting to use this tool - it greatly simplifies things.

After the meeting, I asked Dan about transactions and if it was possible to use Hibernate instead of the RowSet stuff. He said that since JSC is based on NetBeans, you could probably write a plugin to use Hibernate instead of RowSets. As far as I know, the main reason you'd use Hibernate is for caching - but rowsets probably have that too. I know that the spec lead for JSF is talking to the Spring developers about JSF-Spring integration, so maybe that will be a future option as well.

Another thing that's not currently supported is the use of great technologies like Tiles or Sitemesh. Sitemesh integration would likely be pretty easy - you'd just never see your decorated UI in the IDE. Tiles is definitely something on the roadmap, but they don't have a solution yet. Dan indicated that using "includes" in your JSPs should work just fine - rendering in the IDE as they would in your browser. Good stuff - I hope we start using it at my current project - I think it'll do wonders for productivity. Since it's based on standards (JSF and RowSets) - the generated code looked pretty clean too.

[ANN] Struts Resume 0.9 Released!

Struts Resume 0.9 is a major improvement over 0.8. Not only did I upgrade all the code to use AppFuse 1.4 (release notes), but I also removed Struts from the services layer. Moreover, you can actually enter almost all of the pieces of a resume and render it in HTML and Word format. The resume-entry piece (and sections you can enter) is largely based on what Monster.com uses. I may add other sections in the future (i.e. awards and publications).

The main reason this is not a 1.0 release is because an administrator is the only one who can edit the HTML template - and the Word/RTF template is not editable online. Allowing a user to override the default template(s) will be the primary goal in 1.0.

Here's a specific rundown of all the changes from the changelog:

• Upgraded to AppFuse 1.4 - Includes Spring and all kinds of other goodies.
  • AppFuse 1.4 Release Notes
• Added Resume Creation/Editing Wizard.
• Added ability to edit HTML Template online (Admins only).
• UI Updates:
  • Background borrowed from alistapart.com. (Thanks!)
  • Changed from ListMenu to TabbedMenu.
  • Changed to fixed-width layout (700px).
  • Added CSS drop shadows to headers.
    • Idea from http://phoenity.com/newtedge/drop_shadow/
    • Hack to fix Safari in web/layouts/baseLayout.jsp
• The Tomcat User's resume can be on the demo server at http://demo.raibledesigns.com/struts-resume/tomcat.html.

Download (~10.5 MB for src, ~5.4 MB for bin), Online Demo and Homepage.

SiteMesh passed the 10 minute test

I decided to go out on a limb this evening and give SiteMesh a run for its money. The first warning sign was that the documentation refers to version 2.0.2, while the downloads section refers to version 2.0.1. So I proceeded to download 2.0.1. I promptly noticed that the install guide indicated I needed to download SiteMesh's two TLDs and configure them in my web.xml. Blech - this is so year 2000 - most modern containers support loading taglibs from JAR files with a URI.

So I did a good ol' cvs co of sitemesh from java.net. First of all, I'd like to say kudos to java.net and their CVS repositories - they've been rock solid for the few weeks I've used them. After checking out sitemesh, the first thing on my agenda was to give it the tried n' true ant test. This means I navigate to the sitemesh folder and simply type "ant". At this point, I should get one of two things - a BUILD SUCCESSFUL with a JAR or a help message telling me what I should type. I got the former, which I prefer.

After this, I integrated it into my app using the decorators documentation and deployed it. At first, I received the lovely ol' "getOutputStream() has already been called for this response" error, so I hacked PageFilter.java to use PrintWriter writer = response.getWriter(); instead of PrintWriter writer = new PrintWriter(response.getOutputStream());. Build, copy, package, deploy and voila - it all worked!! Wow that was easy. ;-)

Here's the weird part. I decided to reverse my hack on PageFilter.java to prove that I'd actually fixed the bug. Now I'm back to the original code I got from CVS and I can't get the getOuputStream() error to rear its ugly head. Doh!! This experience begs the following question.

Is SiteMesh stable enough on Tomcat 5 that I can should use it in my Spring Live sample app?

SiteMesh definitely passed my 10 minute test, we'll see if it holds up for the long haul. So far, I'm quite impressed with its easy configuration and quick implementation. I especially like that you can literally guess at it's syntax and you'll get it right. Maybe I was just lucky...

P.S. You should probably know I'm a big fan of Tiles. I wonder if SiteMesh will let me switch a decorator on the fly like Tiles does?