NFJS Keynote - The Art in Programming

Let me start with this: Dave Thomas is an incredible public speaker. If you ever have the chance to hear him speak on something even remotely relevant to your life, take the opportunity.

His first recommendation: read "The Mythical Man Month" by Fred Brooks. I've linked to it for your convenience, but I'm not an Amazon affiliate so don't worry, I'm not getting anything if you buy from them. As much as I've been hearing about this book in the last year or so, I guess I'm going to have to read it to see what all the fuss is about.

His keynote on "The Art in Programming" was very well crafted. After a few cursory jokes about Software Engineering he began to explain why he views coding as more of an art form. He made three allegories, and I felt them relevant enough to write them down. Not a lot of notes mind you, but it was a keynote.

1. Authors & artists often struggle with getting started (aka Writer's block). I've seen this before in programming, and his suggestions were:

• Start anyway - rapid prototyping
  
• Prototype the application - Not UML though. Use another medium. He suggested using Duplos and a group of developers to diagram the program. He suggested that soon Red bricks would be model beans, and yellow would be controllers, etc. Very fun idea, as I already love Lego.
  
• Test first - If nothing else, write tests first.
  

2. They also commonly have problems knowing when to stop. Dave's suggestions:

• Set boundaries (space/time) - the smaller the better. Do mini-iterations to get it working.
  
• Plan for feedback from your user.
  
• Partition the app into components so that they can easily be reworked if something comes up.
  

3. Always remember that art is all about satisfying the customer, he suggested:

• Look beyond the surface of the reqts - see if there's something more that you can deliver/develop at little cost. See the last bullet for more explanation.
  
• Work with the client - make sure you're getting feedback in the loop.
  
• Look for the emergence of spontaneous things that surprise you, and could lead to better code or a better application.

Overall it was a keynote, and it was very fun and lively. A great discussion, definitely solidifying programming as something between Engineering and Art, but clearly not solely either of the above.

NFJS 1.3 - Politics of Persistence

This session started with a great history of the persistence wars, full of mystery, intrigue, deception, and all that other stuff that makes a great movie, but not such a great standard (or product for that matter). I told Ryan when we were walking out that I felt like I could read an article on TSS on persistence now, and at least keep up, if not be able to contribute something remotely useful. Obviously the speaker, Bruce Tate, wasn't just going to say XYZ is the persistence framework you should be using, since there is obviously a lot to consider with regard to which one to choose, but to sum up the presentation he gave the four he likes best.

To be fair, one of them is ruled out pretty quickly because it is the persistence model for Ruby on Rails, an idea called Active Record. Not particularly useful for us Java folks, but worth nothing all the same.

His first recommendation was for highend solutions, a JDO implementation called Kodo. Haven't had a chance to evaluate it, but it sounds like it has some very nice management screens, even to the point of being able to suggest what classes should/not be cached, or what resources should be brought from the database together, as opposed to using two different queries.

The second recommendation, when you can't beat the price of free is Hibernate, and finally he recommended a class of tools I believe he called 'JDBC Helpers' i.e. Spring and IBetas/IBase/... (I dunno, I'll try to clarify tomorrow, or maybe Ryan caught it).

Anyway, after the talk I asked Bruce what he thought about Spring and he suggested that if we went forward with Spring since it can sit on top of Hibernate or JDO, that if we chose the wrong persistence framework we'd be more free to switch among them, which is a huge plus in my mind.

Finally, as the class was wrapping up one of the people in the back suggested a quick informal poll of how people were mostly doing their persistence. Probably 2/3 of the people raised their hands signifying JDBC directly, or a custom framework. After that the majority in this session were doing Hibernate, probably another 20% or more. Then just a few otherwise. Not very scientific, but definitely interesting.

NFJS 1.2 - A Bag of Tricks For JSF

Pretty good session, several tips/tricks for the best practices with JSF.

1. JSF and Spring can be easily integrated, and you can map forms to Spring beans (POJOs that reference the database). If I knew more about Spring I might think this was incredibly useful. From what I gathered today Spring is a framework that sits over top your choice of persistence framework(s). My next post should have a little more on choosing a persistence framework, but as a teaser, Spring might not be too bad of a choice.
   
2. The second tip was a suggestion on a practice for how to handle people clicking the back button after submitting a form, and then submitting it again (and how to do this in JSF). Rather interesting. He set a field in the session and put it in the submit request. Then when you commit the transaction you check that the variable in the session matches the variable in the request, and you clear the variable out of the session. That way, if they hit the back button, and then re-submit the form they only have the one in the request, and you can redirect them to a page explaining why you haven't double billed their credit card, and how they need to get training before using your Internet again. I kid. :)
   
3. Finally he showed a way to automatically highlight required web fields with an asterisk, by overriding the default behavior in JSF. Kinda cool, mainly because he showed us how easy it would be to write your own custom GUI components in JSF and allow other applications to use them. It's supposed to be as simple as creating a JAR of the overriding components, as well as the .tld and jsf-config.xml, and the new app will have the additional components available to it. I guess we'll see sometime, after two sessions on JSF, I'm going to have to give it at least the "old college try."
4. I saved the best for last. Although completely unrelated to JSF David showed us a product called Canoo WebTest. The gist of it is, and I can't wait to explore it on Monday, that WebTest is a set of Ant tasks that sit over top of a tool called HTTP Unit. You easily write tasks to populate fields on a web form, click buttons (and links I assume), and then verify the output on the following page. Basically what it allows you to do is write a simple xml build file with a set of integration tests for your application. One really cool feature of this is that the tests can use the same properties file that your application does, and so changing things in the properties don't have to break your tests.

Finally, coupla blogs to keep on your watch list:

http://jroller.com/page/dgeary
http://raibledesigns.com/page/rd

NFJS 1.3 - Shale: The next Struts "?"

This session was presented by David Geary who is one of the Shale developers along with Craig McClanahan (also Struts developer) and another colleague of his. Shale is an extension to JSF and Craig's proposal for Struts 2.0 although there is no connection between Struts and Shale. JSF lacks quite a few things (as mentioned by RC in the JSF Session) due to the rush in its development and Shale fills in those holes.

David's inclination towards Shale architecture over Struts was pretty obvious. Although it wasn't completely mentioned why choose JSF over Struts in the presentation nor was it brought up by any of the attendees, I found the following top ten reasons why prefer JSF over Struts on David's blog http://jroller.com/page/dgeary

1. Components
2. Render Kits
3. Renderers
4. Value Binding Expressions
5. Event Model
6. Extensibility
7. Managed Beans (Dependency Injection)
8. POJO Action Methods
9. JSF is the standard Java-based web app framework
10. There's only one Struts

However there was quite some discussion over the adversary between Shale and Struts. According to David, Struts architecture does not hold a very high place among the list of the best framework options around and offcourse JSF being the best one followed by Tapestry, Webwork, others and then Struts. Part of the reason is Struts is quite an 'old' architecture. According to Craig McClanahan (the founder of Struts) "Struts will become gradually less relevant for new application development unless it adopts JSF strongly". Craig is throwing away the framework that he built himself.

David covered the features that Shale provides and I will describe a summary of those. The presentation was based on a demo of a user profile (account) creation page and Shale on JSF was used to create the functionality. The Symposium CD contains all the code for the demo. The main features that Shale offers are:

• Web Flow
• Remote Method Calls
• These two are the basis for AJAX (Asynchronous JAvascript with XMLHttpRequest)
• Spring Integration, Shale works out of the box for Spring
• HTML Views
• Tiles Integration
• Using Tiles View handler (JSF extension point)
  
• Client and Server-side validation, JSF 1.1_1 does not provide any client side validation
• Utilities
• Back Button abuse
• File Uploads (may not happen)
• JNDI

There are three different paths that future Shale can take

• Struts 2.0? There has been a lot of push back on the dev forums and so it is unlikelyto happen
  
• A new Apache Project? Most likely scenario
• Absorbed by MyFaces?

JSF extension points are used to add objects in the JSF by specifying them in a config file which are then taken over by Shale and action is performed. Shale is currently under development although the current releases can be downloaded bundeled with Struts nightly releases. According to David, it will take a year to couple of years for this frame work to completely develop and now is the time to learn it. Offcourse they always want people to be contributing to its development. Five tags are provided in Shale's tag library.

• s:token
• s:subview (life cycle tags)
• s:commonsValidator (this tag can be embedded in JSF input tag)
• s:validatorScript (writes the java script for all the commonsValidator tags used)
• s:clay (lets you parametrize JSPs to be used for various beans to avoids repetition)

Tokens disallow the duplicate submission through the back-button (as also mentioned in the JSF session). Tokens can be used by adding the s:token tag to the form and embedding the error message in between.

JNDI objects can be accessed by using built-in jndi variables in the EL, and specifying the objects under JNDI.

Remote Method Calls are used for AJAX. Currently this feature only supports remotely generating XML by using Jakarta-Commons chains. Remote chain commands are defined in the config and a call is made from the server side using the command name. Java Script will be supported in the future.

Spring with Shale is easier than with JSF. Shale uses Spring's delegating variable resolver and accesses the Spring beans from JSF expressions. The implementation requires only the addition of shale-spring.jar to WEB-INF/lib

Shale can be used to provide extra support for Tiles with JSF. tiles tags are inserted in the shales subview tag and the views are specified as tiles. This allows to load tiles directly rather than specifying a jsp for each tile.

Shale provides both Client and Server-side Validation by using Commons Validator and Validator Script tags. A commonsvalidator tag is attached to the input component and a type (required, credit card, etc) can be specified. The validatorscript tag in the end then produces the Java Script necessary for validation at the client side. (Writing Custom Java Script methods was covered in the JSF session).

The idea of Retro Views comes from Tapestry. The idea is that HTML elements can reference the JSF components which are actually defined in XML (in clay-config.xml) . 'jsfid' attribute is used to tie the HTML elements to the JSF components. There are two modes for these views, the preview mode where the page can be referenced as .html extension and it enables the Graphic artists to work with the HTML part and the Runtime mode which is used by the developers and end time users and can be referenced with the .faces extension. There is a custom view handler in JSF that reads the corresponding html, renders the components and then displays the page.

Shale Web Flow is modeled after the Spring's Web Flow. it consists of Dialog, states and transitions. Dialogs are defined in /WEB-INF/dialog-config.xml and can be invoked with the JSF expression language.

Overall, I think it was a good intro session to the capabilities of Shale and what it adds to JSF. But I think it will be still a while before this framework can be used and definitely not till they decide what the future of Shale will be, Struts 2.0 or something new?

NFJS 1.1 - Java Standard Faces

Stupid Embassy Suites doesn't provide free wireless...Guess I'll write these entries in the evenings.

So JSF is the standard for GUI components for web applications. I can't remember if Joel/Eda wrote about this before. JSF is a very interesting amalgamation of Struts (MVC for the web) and Swing (gui components for client applications). One great thing about JSF is that it is the standard web application framework, developed accoring to the JSR specification and approved by the JCP.

JSF has an controller servlet, nearly identical to Struts, but it makes actions and beans much more simple than Struts does. No messy mapping of form values into your beans, JSF handles this for you. Another big advantage over Struts is that the configuration file (at least at a superficial glance) seems considerably more manageable. Again, similar to Struts, it can populate the form for you, and there are simple hooks for validation. Actually, there are custom tags that do some of the basic validation for you.

Like Swing, JSF defines reusable GUI components, by way of JSP custom tags, that you can easily drop into your JSPs, providing layouts, and an event model. This is great because you can add server side events for things that you might normally only be able to detect with JavaScript. However, this is tricky because if you're not careful every click of the user's mouce will generate a round trip to the server. In David's example his example app actually round tripped to the server when he clicked a checkbox.

Another key thing to realize with JSF is that you can extend anything. Don't like the implementation of the HTML for an object, extend it and replace the default one in JSF. It's amazingly extensible, for good reason, as you shall soon read.

A final thing that should be noted is that to hear David Geary talk about JSF it was created as a replacement for Struts. Is it ready to do that? Maybe, maybe not. The team developing it was rushed to finish it since it simply sat for some time, and so they felt pressured to get a product out as soon as possible and it's missing some features that they would have liked to have developed. Thus they focused on extensibility so that they could revisit in JSF 1.1 or 2.0 without breaking anything. I think it's in a very usable state, although there are definitely some gaps to be filled, possibly filled by "Shale." We shall see.