Server-side applications require stripped-to-bare-metal efficiency to conserve processing resources. Are your pages as efficient as they should be? Here's how to leverage JSP to increase efficiency in sharing data between pages.
Server-side applications require stripped-to-bare-metal efficiency to conserve processing resources. Are your pages as efficient as they should be? Here's how to leverage JSP to increase efficiency in sharing data between pages.
JSP makes server-side programming extremely convenient and powerful, offering functional isolation in its favored application architectures and a high level of compatibility with other APIs. It takes little time to knock out an effective page and place it cleanly into an app, and you’ll face the usual challenges when tying the app to databases and users. Here’s a start on passing data between pages.
The JSP application frameworkIt’s important from the outset to understand the architecture of a JSP application. JSP apps adhere to the MVC design model (Model-View-Controller), a variation on the conventional three-tier architecture you’ve seen in other Web apps. There are some differences in the JSP/MVC model: Model refers to application logic and data; View is presentation; and Controller is request processing.
In JSP apps, it is common to create a page for each step in the client-server interaction. You’ll generally create pages for each functionally distinct step in the interaction: For example, you might have a Data Entry page; a Validate Request page, a Search Database page, a Query Database page, and pages for subfunctions of these pages (an Insert page, a Delete page, etc.).
Once you’ve adopted this framework, it becomes a matter of handing off control, one page to another, as the application executes.
Handing off controlWhy would you need to pass anything around, if every page is a self-contained piece of the puzzle? Well, as handy as the MVC model is, it doesn’t cover every situation. It’s intended to facilitate apps that artfully and efficiently combine JSP pages, beans, servlets, and other server-side components; that is, the MVC roles can be assigned to the different types of components, depending on what’s appropriate for the app.
It will often be the case that JSP will be used for View and Controller (i.e., presentation and request processing), the two pieces of the app that the user has in hand. In this case, control must be passed from one page to the other; you have a multipage request-processing mechanism and the pages must work together.
The first rule in handling such a situation is this: To pass data from one page to another, you must pass control from one page to another.
Moving forwardWhen, in the course of request processing, you pass control from one JSP page to another, you’re doing more than advancing to a new block of code, or leaving one application function for another—you’re also handing off the original page’s information pertaining to the request. The receiving page now has it, with the assumption that control will not return to the originating page. It’s basically an effortless hand-off, almost effortlessly achieved, with the following tag:
Note: The logic needed to move through your application, planting such transfers as conditional branches, is trivial, but harkens back to the dangerous days of the BASIC command GoTo—use with caution.
There are two things you need to know about forwarding: first, you can pass additional parameters to the destination page by embedding the tag
, listing the additional parameters; second, the
page attribute assumes the destination page will be found in the same path as the current page—otherwise backslashes and a revised directory path must be included.
Different scopesIn passing data objects around between pages, JSP assigns a
scope. You control this, and it’s an important feature. You can open up a data object to a single page or multiple pages, a single user, multiple users, or all users; and you can keep it live for any period of time you like. The default is, of course, the minimum—an object’s
scope is limited to the actions in its page of origin.
This
page scope can be superceded by a
session scope, which opens data objects to a particular user, from one request to another. A variation on this is the
application scope, which shares data objects among all users of a particular app. Last but definitely not least is the
request scope—if a user request bridges multiple pages,
the data objects are shared across those pages.
Where can this be set? In the bean encapsulating the data object. It looks like this:
When you use a data object in a JSP page, it should be a Java class; i.e., make it a bean. Encapsulating application logic into a bean means you’re passively adopting a business components architecture that will make your app components highly portable.
Why do JSP apps primarily use beans to handle data objects?The idea is to remove as much application logic as possible from presentation—remember the MVC model! What you’re shooting for is to make JSP as much about user interaction, i.e., display and output, as possible.
You now have the means to pass control from one JSP page to another, and in so doing, pass access to data objects. Remember to use the correct scope. Take it from someone who has made the mistake of assigning the wrong scope to a bean; you can become incredibly confused when data objects are accessible in all the
wrong ways, because the mistake isn’t readily apparent in the code.
To achieve what you are generally shooting for—and what was desired in the example of a multipage request—you’re frequently going to want to use the
request scope. Remember that this is the one that enables the sharing of data objects across pages.
