Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

dws (341)

dws
  (email not shown publicly)
http://www.davewsmith.com/

Journal of dws (341)

Tuesday July 29, 2003
12:18 AM

A maze of twisy little ecosystems, all isolated

[ #13746 ]
I've spent a bunch of time over the last two months reading J2EE books--Tomcat and Struts books in particular--looking for "best practices" for assembling an application. My partner is worrying about the database side of things, while I sort through schemes for managing sessions, JSP usage patterns, error handling, templates, unit testing, and overnight build stuff. We had a meeting today to hash out open issues.

In trying to fit together all of the best practice advice we're collecting, it's become pretty clear that many folks in the Java world have gotten so deep into their particular ecosystem that they have forgetten that others exist. Recommendations conflict. One camp rallies around "Use our marvelous class library, and do X, not Y!" (Where Y is something like embedded raw Java in JSPs), and another camp has a wonderful set of data access patterns that, uh, end up requiring intermediate bean objects to avoid putting raw Java in JSPs (thus cancelling out one of the benefits of the patterns). One camp decries putting anything besides cached data in the session object, while another camp has an otherwise marvelous form validation strategy that pretty much requires stuffing form data into the session object. Hello, leakage!

I get the impressions of small groups working in isolation, each clawing through the pain of building J2EE apps, offering up their particular scar tissue as a solution without first stopping to share notes.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A maze of twisy little ecosystems, all isolated 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Java Strategies (Score:3, Interesting)

    by chromatic (983) on 2003.07.29 0:56 (#22493) Homepage Journal

    The nice thing about Java is that BOTH camps have their own STANDARDS!

    About half the time I look at a framework like Tomcat or Cocoon, I think, "That's really neat! To do useful things, you only have to implement these methods. All of the hard work's done for you." A few hours later, I realize that actually implementing those methods represents quite a bit of busy work anyway.

    • And Struts is pretty nifty, until you realize how incredibly messy it can be to handle validation--particularly validation failures--when your form has been generated dynamically. Tabular data? Sure, Struts has tags to make that easy. Tabular forms? Uh... uh...
  • Any moderately complex application development environment is going to inspire the same sorts of camps to form. What struck me about Java web application development is how many similarities there are with Perl web application development. There are a few truths that for me were very consistent (in no particular order):
    • Do not put code in your templates. Ever. Use taglibs (Java) or plugins (Perl/TT) for nontrivial work.
    • Use an intermediate templating language for simple constructs like loops and conditionals. (This wasn't as possible in Java a couple years ago, but JSTL has made this much, much easier.)
    • Templates should never (well, almost never) access the data layer directly.
    • Database information should be brought in via objects rather than data structures. Tools like Hibernate (Java) or SPOPS/Class::DBI/etc. (Perl) make this simple. Passing along Maps/hashes seems very appealing at first, particularly with RowSetDynaBeans (in the commons-beanutils) and DBI's fetchrow_hashref, but you'll eventually want to add calculated fields, or standard formatting, or whatever, and then you'll be screwed because...
    • Code that feeds the data objects to the templates should not do any formatting. This includes pulling data out of objects for 'easier' template access. (Sorry HTML::Template folks...) This also includes summarizing data into separate fields. All the code (usually known as an 'Action') should do is assemble the data and make it available to the template. Anything else will eventually get you into trouble.
    • Formatting code should be centralized so that dates, money, names, etc. all appear the same everywhere.
    • Templates should be reusable for different actions, componentized if possible. That is, if I have a non-editable list of users I want to define it once and pass a collection of users to it from everywhere. (And if they're not componentizable you probably should pick a different templating technology...)

    (there are probably a few more but these were on top of my head...)

    And finally: a good framework (like Struts, or OpenInteract) should encourage you to do the right things by making all of the above easy.

    • I'm mostly with you on this. The Struts "tiles" taglib (and the older, deprecated struts "template" taglib) are an elegant way to do templating. But heaven help you if you dare to either construct an <html:form> dynamically, or put multiple forms on a page. Dealing with validation failures becomes a nightmare, unless you're willing to violate another best practice by using the session object to cache everything you need to reconstruct the page that holds the form(s). If the user abandons the form, you
      • That's one of the core assumptions Struts makes under the guise of usability. And for the simplest CRUD applications it works fine. But once you build pages with more than one set of data to act on or something similar you're screwed. Super irritating.

        This assumption also points out one of the other irritating struts features: passing "the" ActionForm to the execute() method. What's the point? You need to cast it to your own form class anyway, and if you're going to do that you might as well fetch it from

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.