Variable Soup - Mmmm Tasty!

At this point, I would like to show you some of the JSP pages we have in our application, but I'm sure there's a clause somewhere in my contract that says otherwise.

Over the long term maintenance and feature-adds on large web applications, your JSP pages can start to look like variable soup. You have 10 to 15 variables being accessed that may have come from any scope, set by any action, somewhere in the process of using that site. Maybe that variable came from a filter somewhere?

Eventually things can become difficult to keep track of. With traditional MVC2-- Struts and WebWork, we are able to tie the request scope back to some semblance of an action. But as we move into rich component UIs, where the lines between URL and scope are blurred, what can a developer do to bring some variable continuity and identity into large applications?

One way you can provide scope over your variables is to use stronger grained references. This means that you possible introduce the concept of a page bean, where all variables you need are located. Here's an example:

#{page.user}

#{page.employees}

#{page.currentStatus}

vs.

#{user}

#{employees}

#{currentStatus}

I would think the latter would be harder to trace within a JSP page because you are coordinating multiple variables that could have come from anywhere. By identifying 'scope' within a 'page', it helps to narrow your search for variables and quickly trace that 'currentStatus' value through your Java code.

Some developers encourage providing scope prefixing in general across their pages, such as requestScope or sessionScope. This becomes very easy to simply ignore when you are dealing with robust variable resolution within the EL-API. The EL-API and it's concept of a CompositeELResolver means you can pretty much pull variables from anywhere you like. Now marry that with a component framework like JSF, and you might be walking into a maintenance nightmare.

What would be nice is if with each of the ELResolvers or VariableResolvers used within JSF, that the developers would provide a scope variable. So a Spring VariableResolver would provide a springScope reserved variable so anyone looking at the pages would know where those variables are coming from-- Spring's configuration xmls.

The next step would be to provide semantic scopes that are meaningful to your domain model. This way you can create and use scopes like orderScope or addLineItem scopes. These scopes would be managed in relation to your business logic and can provide more maintainable grainularity to variables used in your view. Essentially it would be like creating a Bean with all of the member variables you need. Really, the issue becomes more about being able to assert inherent lifecycles around known business processes.

Does anyone else experience this tracability issue with the 'global variable' phenomenon within large web applications? Does anyone have any suggestions on how to make variables in the view more maintainable?