The following is some prototype (throwaway) code, written to demonstrate how front-end developers can interact with my stateless session beans.
It's a nice, straightforward interface which is fairly intuitive. Select a skill and click the add button to include in your profile. The form will get POSTed, the selected skill and a default level added to the database, and the form redisplayed. Select the level (0-4) of familiarity with a particular skill or click on one of the delete buttons to remove the skill from your profile.
It's actually a fairly simple page, once you discount the EJB interface code, but it uses three JSP elements: directives, declarations and scriptlets. The directives are at the top of the file, enclosed by <%@ and %>. The page directive in this case indicates which classes the generated servlet will require. The declarations are enclosed by <%! and %> and exist at the class level, i.e. they are not included in the generated _jspService (per-call) method. The scriptlet code (enclosed by <& and &>) is included in the _jspService method.
We override the jspInit and jspDestroy methods in in our declarations section in order to obtain and release references to EJBs. It's more efficient to do this at the class level since we incur the overhead of the lookups only once. The first person to access the page will likely notice a slight delay but certainly not as much as the one which results from modification of the source. In that case the server has to compile the source down to a servlet.
There are three scriptlets in this code. The first one is executed as soon as the _jspService routine is entered and is responsible for processing the form contents, if any. It interacts with the stateless session EJB to maintain user information in the back-end database. If a user adds a skill, deletes a skill or modifies a skill level, the information is both reflected to the database and maintained locally in a Hashtable. It's important to note that all of the submit buttons in the form have the name attribute defined. That way the value of the element is passed as a parameter so that we can access it using the request.getParameter() method.
I didn't get around to programming the JSP error page as this was never meant for production. Still, it does illustrate some of the basic concepts and works quite well. Those of you familiar with servlet programming will observe how I use the response.sendRedirect() method to move to the next page. I simply prefer this approach to one which uses all kinds of intermediate pages, such as in the Sun examples. So whether you write servlets and import the HTML or write JSPs and include the Java source, the end-result is the same. Six of one, half-dozen of the other.
Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 by Phil Selby. All rights reserved.