Raible Designs

AppFuse 1.0 Released!

I feel this release deserves the big 1.0 designation because it is an up-to-date representation of my learnings and my perceived best practices in building web applications. Of course, as I learn more, I will continue to push out new releases.

In this release, I did a lot of refactoring and enhancements to existing features. The DAO and Manager interfaces are no longer tied to Struts or Hibernate. Hibernate's Session object is now passed as an argument into Manager and DAO constructors, rather than method signatures. The DAOFactory was refactored by Bear Giles to use reflection to instantiate Hibernate DAO's. Now, if you add a new DAO, you don't have to edit DAOFactory and DAOFactoryHibernate. To insantiate a new DAO, the code is now:

LookupDAO dao = (LookupDAO) DAOFactory.getInstance(conn, LookupDAO.class);

...where conn is a connection object retrieved from ServiceLocator or ActionFilter. When you add new POJOs, you still have to add them to ServiceLocator (for JUnit tests) and hibernate.cfg.xml, which is kindof a pain. I'd like to figure out a way to tell Hibernate to just look in appfuse-ejb.jar.

<tangent>
I still don't have a Factory for Managers, and I don't know that there's a need for one, but it's something I might add in the future. Managers are still creating using: LookupManager mgr = new LookupManagerImpl(ActionFilter.getConnection());. One thing I've been thinking about is the ability to switch webapp frameworks - kindof like you can do with Persistence Frameworks and the DAO Pattern. It'd be cool to add a way to switch (at build time) to use WebWork or Tapestry. Maybe by replacing values for the controller in web.xml. It'd probably be a pain since I'd probably have to create new JSPs for the new frameworks - but it would probably be a great learning experience.
</tangent>

The Remember Me feature has been refactored so the username and password cookies are only available under the /appfuse/security url-pattern. I also changed the posting to "j_security_check" in LoginServlet from response.sendRedirect to an HTTP POST, using Jakarta Common's HttpClient. The reason I have a LoginServlet vs. just using action="j_security_check" in my <form> is to encrypt passwords.

I've developed 3 different applications using AppFuse (struts-resume is one of them), and I have found that it's a pain to upgrade to new versions of AppFuse. Because of this, I don't recommend upgrading unless you really need to. I will be upgrading struts-resume to AppFuse 1.0, but I doubt I'll upgrade it to any future AppFuse releases - it's just too much work for not much reward.

• Download (~11.5 MB for src, ~3.9 MB for bin)
• Release Notes
• API Documentation and Source
• Mailing List

JSTL Tips o' the Day

Here's a couple of tips to help you in your JSP development with JSTL:

• The <c:out> tag has a default attribute you can use to provide a default value when the value in your the variable you're trying to write is null. This is much easier than using if statements. Example: <c:out value="${user.firstName}" default="None Given" />.
• You can populate dynamic values in a key from your ResourceBundle using the <fmt:param> tag. For instance, if you have a message with a link in ApplicationResources.properties - and you want to populate it with a struts-forward, it's easy with JSTL:
  
  ApplicationResources.properties:
  
  

  mainMenu.link=Click <a href="{0}">here</a> to return to the Main Menu.
  

  In your JSP:
  
  

  <fmt:message key="mainMenu.link">
    <fmt:param><html:rewrite forward="mainMenu"/></fmt:param>
  </fmt:message>
  

Usually I try not to put any HTML in ApplicationResources.properties, but I don't think a minimal amount hurts anything. Of course, you could put all the HTML in your JSP, so mainMenu.link changes to "Click {0} to return to the Main Menu." and your JSP changes to:

<fmt:message key="mainMenu.link">
  <fmt:param>
      <html:link forward="mainMenu">here</html:link>
  </fmt:param>
</fmt:message>

Enjoy!