Jsp Practice : Don't User jsp:useBean on Session Scope Attributes

My first best practice is a low level detail.

It's common to things like the following:



instead of doing the following:

<% String myVariable = (String) request.getAttribute("myVariable"); %>

There are some good reasons to utilize jsp:useBean. In addition to being easier to read, it becomes a self documenting way to tell other programmers the list of attributes used in the jsp file.

There is one issue with this approach in that the default behavior is to create the bean (using the default constructor) if the attribute doesn't exist in the identified scope. This may not be a huge issue for request scoped variables, but it can be a problem for session scoped. Imagine doing this.




If myBigObject doesn't exist in the session, it will be constructed and stored there. If you're object requires a lot of memory, takes time to construct, or if its existence in the session triggers some business logic, then the declaration above will cause you big problems. Chances are you won't find the issue until you work on another page that uses myBigObject and are puzzled over how it got in the session in the first place.

So bottom line rule of thumb:

• Use jsp:useAttribute for request scoped attributes
  
• Do not us jsp:useAttribute for session or application scope attributes

Agile development of your team's best practices

Our development team at TripConnect consists of a number of full time employees and also contractors that we bring in to supplement our efforts. Over time, we've been able to develop documentation, code examples, and other means to convey our development practices to developers that join our team. Read this before working on a data access object. Use this class as a model for developing your new Action class. Use this Eclipse snippet for importing this tile...

We can't afford to develop a full developers guide to our code base and the pieces that we do standardize tend to be reactive. When something that 'smells bad' during a code review, we educate the developer, and then (hopefully) we define the best(or better practice).

So my next few entries will cover some things that we discovered during the tenure of our last contract developer. He was a good developer; fast, smart, could read code very quickly, etc, but he had some coding tactics that we needed to address. Most of them were classic issues stemming from a lack of documentation on our part and his own inexperience in developing maintainable code. So for the first practice in this series, here's a very (very) basic set of guidelines on building up an agile process for documenting best practices:

1) Start with some basic coding practices. (Look for this type of code in this folder... Here are some important utility classes. Use this class as a coding example).
2) Inform new developers on practices, code examples, etc.
3) Get the developer working quickly.
4) Spend the bulk of your time educating the developer on the key business and functional requirements.
5) Allow the developer to develop the initial solution with minimal technical information on developing the solution.
6) Require frequent check ins from the developer
7) Follow check-ins with some basic QA and followed by code reviews.
8) Feedback to the developer areas of the code that need changing.

This is pretty basic, so I will dive into more details in some of my upcoming entries.

Happy Holidays!