Raible Designs

How do you i18n your drop-downs?

As I'm developing this morning and pulling a drop-down list from the database, it hit me - I'm not internationalizing these drop-down values. Sure, putting them in the database makes it easier for admins to edit the values, but if a user visits the site with a Spanish locale, they're going to get English drop-downs. So how do I fix this?

Is the best solution to put the drop-down choices in Struts' ApplicationResources.properties file so that I can render the values with <bean:message/> or <fmt:message/>? How do you do it in your webapps?

In some cases, I guess it doesn't matter as the values need to be in English. Take for instance, AppFuse's edit user screen (user/pass: mraible/tomcat). The list of roles comes from the database and should always be in English because the form-based authentication depends on having an English role_name value in the user_role.role_name column - since this is the value coded in web.xml.

AppFuse 1.3 vs. 1.4

Mike Lawrence (the guy who wrote the AppFuse on Orion tutorial), sent me an e-mail yesterday asking about AppFuse 1.3 (the latest release) vs. 1.4 (still in CVS).

Spring
This looks like a pretty new framework. I wonder how stable it is? 

How far along are you with 1.4? You've made more changes to 1.3 to move
to 1.4 than I've made to 1.3. So, I'd be better off just taking your 1.4
base and integrating my changes.

Did you eliminate struts as the MVC framework?

Doesn't this invalidate your awesome AppFuse tutorials?

I'd really like to stay in sync with your new release, however, I've got
major production deadlines to meet. It would stink if I automated a
bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to
1.4, will I be facing stability issues and no tutorial docs?

I figured it'd be better if I answer his questions here, as other folks might be wondering the same thing.

Spring - how stable is it?

As with most open source projects, the version number doesn't always indicate the stability of a product. Roller hasn't reached 1.0, but I would venture to say it's a mature and stable product. If you asked this question on the Spring mailing list, you'd likely received a lot of responses saying that it's very stable and used in many production systems. IMO, it's a very stable framework and likely to be the next Struts (in terms of popularity). I don't know that it's MVC framework will be that popular, but it's persistence support classes, declarative transactions and AOP framework are pretty slick. The fact that it integrates smoothly with all leading MVC frameworks is a nice touch too.

I think the best answer is - you need to work with Spring and then decide for yourself. I love writing one-line DAO methods for Hibernate...

How far along are you with 1.4?

If you're already started an application with AppFuse version x, then you should stick with AppFuse version x until your project is finished. It's often a real pain to upgrade an existing app to use the latest stuff, and probably unlikely you'll gain that much value. However, if you're not under a tight deadline - and you really need something in a more recent release - it makes sense to upgrade. The tutorial I wrote on upgrading a 1.3 app to 1.4 is probably a one-time thing. I don't plan to do an upgrade document between all releases.

That being said, if you have enchancements for AppFuse and want me to roll them into the main code base, the best way is to create patches for the CVS version and then it'll be easier for me to figure out what you changed.

Did you eliminate struts as the MVC framework?

Definitely not - Struts will remain as the standard MVC framework because it is the most popular and most AppFuse users will likely use it. When I add MVC alternatives, they will be packaged similar to the iBATIS option - so you'll have to install them. Most MVC options will likely rip out Struts and replace it with their own stuff.

Doesn't this invalidate your awesome AppFuse tutorials?

The tutorials will be updated to support the latest release. I hope to have some time in early March to update these. As soon as I do, I'll release 1.4.

I'd really like to stay in sync with your new release, however, I've got major production deadlines to meet. It would stink if I automated a bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to 1.4, will I be facing stability issues and no tutorial docs?

Staying in synch with AppFuse as I push out new releases is probably a waste of your time. I did it with Struts Resume for a long time, and it's a lot of work trying to keep up. I firmly believe that each release of AppFuse has been a solid one - they just keep getting better. The only reason to upgrade is for new features and/or bug fixes. I believe that 1.4 will be just as stable as 1.3 and there will be tutorial docs when its released. As far as your automation stuff, the best way to get that added is send me patches against CVS.

BTW, Mike has integrated Middlegen into his AppFuse-based project. He's also working on generating stubs of a lot of the DAO/Manager/Action files - I believe that's his automation stuff. Thanks for giving back so much to AppFuse Mike - now if I only had more time to keep up with your enhancements. ;-)

[Review] Java Open Source Programming

Today I finished reading Java Open Source Programming. It took me one week to read - and I only read about an hour a day. This book is nice to read - you can breeze through 20 pages in no time. I appreciate a quick-read technical book. I enjoyed the simplicity of this book, especially since I'm such a rookie at WebWork, SiteMesh and Mock Objects. I knew most of the Hibernate and XDoclet stuff, but I did manage to pick up a few tricks, and since it's the only book on Hibernate (that I know of), I'll refer to it when I need to do components or proxies. Overall, this book made WebWork and SiteMesh look like great technologies and I'm excited to start using them.

The sample app, PetSoar, continues the "call your persistence layer from your action class" that I've seen in all WebWork sample apps. I still don't know if this is a good idea, but since Actions aren't tied to the web, maybe it is. This means you put your business logic in your controllers (a.k.a. actions). Kinda breaks the whole controllers should only be controllers mantra, but whatever floats your boat. To be honest, in AppFuse, all the Managers (a.k.a. business layer) do is transfer POJOs to ActionForms, and then back again. The Managers are were my business logic should go, but I often find it easier to put it in my actions. I sense a paradigm shift - will the WebWork version of AppFuse only contain a "dao" layer and a "web" layer? Who knows - only time will tell.

One interesting thing I picked up is the different way that Dependency Injection (a.k.a. Inversion of Control) is handled in WebWork compared to how its handled in Spring. In Spring, all you need to do is add a setter (and local variable) to prepare a class for IoC. When using WebWork, you have to create an Interface that has the setter defined, and then your Action must implement that interface. If Spring can do it without an interface, why can't WebWork?

All in all, I enjoyed this book - though it didn't peak my interest as much as J2EE Design and Development. I think that's probably because Spring solves some issues I've had with AppFuse (binding interfaces and implementations), whereas this book doesn't really solve anything for me. As a WebWork newbie though, I do feel this is a good read. I also found myself saying "Wow, that's cool" a fair amount of times (re: SiteMesh and WebWork).

I was disappointed that i18n was not covered at all. I tend to always prepare my Struts apps for i18n (extracting text into a .properties file). However, in most cases, a 2nd translation has never been put in place. So, I bitch about the lack of i18n coverage, and I write my apps with i18n in mind, but it's never been used in any of the apps I've written. Maybe I should just quit doing i18n in my apps - it'd probably save an hour a week of development time.

So it comes down to this - if you don't know anything about WebWork, this book is a worthwhile read. If you know WebWork - I'm sure you'll be disappointed because it is written for newbies.

Next up, upgrading my programmer certification to 1.4 with the Sun Certified Programmer & Developer for Java 2 Study Guide.

[Review] J2EE Design and Development

I finished reading Rod Johnson's J2EE Design and Development today. 700 pages took me a little over 2 weeks to knock out. This book is definitely targeted at experienced J2EE developers, which is nice. I tried to do the same with my Struts chapter in Pro JSP and I wish books would do more of it. However, the problem with targeting a more experienced audience is you lose a lot of potential buyers. Rod is definitely one sharp fellow and it shows throughout this book. Either that, or he's just got a lot of experience working with the J2EE stack in his career.

The framework described in this book eventually became Spring - and it's really just a culmination of all the things that Rod has used on his previous projects. In that respect, it's similar to AppFuse, which I created to assist me with my Java webapp projects. Like Spring, AppFuse contains all my learnings and choices over the last couple of years. Just to be clear, I don't mean to imply that AppFuse is anything close to Spring as far as functionality - but I do believe they're similar in their goals. Spring is designed to make J2EE easier, while AppFuse is designed to make project setup and testing easier. Hopefully, when I start using some Spring features in AppFuse, developing with AppFuse will become even simpler.

Back to the book. I found the first few chapters somewhat boring since they covered a lot of the stuff I already knew about J2EE applications. The middle part of the book was on Spring's simplified JDBC approach and it also covered EJBs. I tend to shy away from writing JDBC these days, especially since Hibernate suits my needs so nicely. If I'm working with an existing database and there's a lot of SQL code already, I'll use iBatis. And EJBs, blech - I've never had a need for them. Admittedly, a lot of my projects are small and don't require container-managed transactions. I've also heard rumors of CMT being a part of Spring - so who knows if there's any good argument for EJBs anymore. Anyway, I found the middle part of the book quite boring as well since I don't much care about JDBC or EJB.

The last part of the book, however, peaked my interest. It discussed MVC design, View Technologies (i.e. JSP, Velocity, XSLT, XMLC, PDF) and basically a lot of stuff related to the web tier. In this area, I was most impressed with XMLC, which allows you to write HTML pages - then use Java to manipulate it's contents. Very slick stuff for having a static prototype that also serves as the code for your app. I don't see myself switching from JSP to XMLC, but I dig the option. In the Performance Testing and Tuning chapter - great examples where given and seemingly real-world optimizations where made. This chapter could prove to be a handy reference for enhancing performance with simple caching.

Overall, I thought this was a great book, although a bit heavy on the EJB stuff for me. Now I'm motivated to learn more about Spring. In the process, hopefully I'll figure out how it makes iBatis and Hibernate easier to work with (links are most welcome). Next up is Java Open Source Programming(500 pages), which I expect to take another two weeks to polish off.

The Verge Web Framework

After reading this post on the Server Side, I'd hate to be the guy who invented Verge. He's getting pounded like a rabbit during mating season!

Personally, I don't think there's anything wrong with another web framework. Competition is good. The funny thing is that I've never had a need to migrate away from Struts. I do admit that the IoC (Inversion of Control) in WebWork looks cool, but I don't have a need. After reading most of Rod Johnson's J2EE Design and Development, I do understand IoC (I didn't have a clue before), but I still don't see how I need it. I've never run into a problem with Struts that I couldn't solve. Maybe it helps that I've written my own app to make Struts development simpler.

Even though I do like Struts, and I do find it easy to develop with, I also plan on stuffing my head in a couple of books and learning all about Spring, Tapestry and WebWork. Why? Mainly because I'm a fool and I can't be happy just sitting on the couch and watching TV (which would probably help my blood pressure and make my family happier). I'm a fool because I'd rather learn than relax. Back to the point - why do I want to learn these "big 3?" To be honest, it's primarily because some big names (and folks I'd consider friends) are saying they're cool and they'll make my job easier. If only I wasn't so easily influenced...

What I hate about all of this is that as soon as I decide to integrate Spring into AppFuse, it becomes more complicated. Yes, an XML BeanFactory file is more complicated than Interface i = new InterfaceImpl(), especially for newbies.

Furthermore, I'm willing to bet that I'll end up writing workarounds for issues I encounter in Tapestry and WebWork. I'll even put my money where my mouth is - if your framework doesn't require me to write any workarounds, I'll donate $100 to the project. Heck, if it really is that cool - I'll donate money regardless of workarounds.

The worst part is that there's really no reason to convert my Struts webapp to these newer, cooler frameworks. About the only good reason is so I can say "I know the XXX Framework." I doubt XXX Framework will make anything easier, but it certainly might make my webapp a whole lot cooler.

J2EE Patterns Catalog

J2EE is simple to learn, simple to develop - especially when Sun recommends you follow a mere handful of patterns. Heh.

Yet Another Web Application Framework: Shocks

From watching the struts-dev mailing list, I discovered a new Servlet Framework called Shocks. The thing that interests me about this framework is that the author looked extensively at Struts and WebWork both before creating it. It's feature-set sounds nice too:

It has an aspect-oriented workflow engine that can add crosscutting
system logic (like form processing, L10N, security, logging, etc) dynamically at
runtime (without having to mess around with the bytecode).  It can trade actions
across classloader boundaries, enabling web applications to span across multiple
.WAR files.  This allows users to drop in a new .WAR with new metadata and new
actions, which updates the application workflow at runtime across all modules in
the application namespace.  It handles workflow versioning and version rollback
(in case you make changes you come to regret).  It does instance pooling of all
components and sequences.  Every aspect of the system can be managed with JMX at
runtime.

Sounds like Spring, eh? Yes, says the author.

I think there are appreciable differences that have yet to be realized between 
the two (I haven't read their code at all), but definitely a lot of conceptual 
crossover.

I would think that introducing a new framework into the mix (and convincing folks to use it) must be pretty tough at this point, unless you create an IDE to go with it or introduce it in a book. BTW, did you know you can use Tiles with Spring.

Vanity URLs in Struts

I figured out a way to make your Struts' app have URLs like the following:

http://raibledesigns.com/weblog?method=edit
http://raibledesigns.com/weblog.jsp?method=edit
http://raibledesigns.com/weblog.html?method=edit
http://raibledesigns.com/weblog.php?method=edit
http://raibledesigns.com/weblog.asp?method=edit

Might be a nifty little trick to try. Pump out a version of Roller with this feature enabled and you could say you made a .NET version! ;-)

Here's how:

1.  I created a RequestFilter that maps to /*
2.  This filter checks to see if request.getServletPath() matches any of the
action paths in struts-config.xml.  If so, it forwards to the action.
3.  As an added feature, I added a set of allowed extensions to this
filter's init parameters.  So far I have .jsp,.html,.asp,.cfm (using .jsp
ensures no one links to them directly, MVC enforced!) - so marketing can
choose what technology they want to convey ;-)

This seems to work great.  For example, I have an "advancedSearch" action
defined as follows:

    <action path="/advancedSearch"
      type="org.apache.struts.actions.ForwardAction" 
      parameter=".advancedSearch"/>

(ForwardAction will eventually be replaced, if necessary, with a real
action).  This allows all of the following URLs to work:

http://site.com/do/advancedSearch (works with Struts by default)
http://site.com/advancedSearch
http://site.com/advancedSearch.html + all other extensions listed.

More information (including source code) can be found on the struts-user mailing list.

JSF: Allows WebWork style Actions

Am I working too late or does JSF allow a WebWork style Action? According to this post, you can have your properties and your logic in the same class (like WebWork). Also, no more worrying about BeanUtils.copyProperties()?

Struts encourages you to use Strings for field values that might need conversion, in order to redisplay correctly in case of conversion errors. You don't need to worry about that with JavaServer Faces, because the redisplay is handled by the components themselves. You will generally use the native data types for your field properties.

Regardless of what the WW Developers say, I think I'm gonna dig Java Server Faces.

PHP vs. Java - which is better?

I have a former client that has a customer. This customer asked them - "so when are you migrating from Java to PHP?" So evidently this person has the impression that the next wave of web applications will be written in PHP. My former client has asked me to provide an answer for their customer. If I translate it, I think they mean to ask "what is different between Java and PHP and why should we use Java over PHP." Here are my opinions - please add yours as you see fit. I must admit I don't know a whole lot about PHP, except that it's widely popular among the Linux/Apache/MySQL crowd and that it's similar to ASP in it's lack of a MVC architecture (yes, I know about the PHP MVC project).

• I think Java is more of an industry standard, whereas PHP seems to be popular among hackers and hobbyists.
• Java provides better separation of layers - key for testability. PHP has all the code embedded in the page, so you have to run it through a browser to test if database connections work (for instance).
• Java is more scalable.
• More folks know Java and it's easier to qualify someone's Java skills. How do you test someone knows PHP? Is there a certification?
• More for-profit organizations use it.

If you're a Java or a PHP-lover, I'd love to hear your opionions (facts are always better). I'm going to point my client to this post, so keep it clean.