Hi,
I've been converting our Web application from servlets to JSPs and I've made
sure that my JSPs are dealing only with business objects implementing
standard interfaces. We have a requirement that our persistent business
objects be able to work with a number of RDBMSs, so my JSPs only "know"
about the business object interfaces and the methods these interfaces
support. I don't do any sort of JDBC access from my JSPs, deferring this
responsibility to an app server (we're currently using Objectspace's Voyager
product for ORB communications, but we'll be moving over to EJB very soon
now). I've also created a bean which acts as a client on the ORB and pass
this between JSPs through the Session object. This design is working great
for us. I've noticed a huge improvement in productivity with JSPs over
servlets, and I was one of these people who used regular expressions and
token replacement within servlets and poo-pooed JSPs initially.
I feel the more functionality that you can encapsulated into beans (whether
in the JSP/servlet engine or in an app server), the better. EJB with the
interactions of Session beans and Entity beans should really further this
along. JSPs become purely presentation vehicles; the task at hand is dealt
with by Session beans and their interactions with Entity beans. By
encapsulating functionality at the app server, you can reuse your beans in
other presentation mediums (for our situation, we are using Java Plugin
applets alongside our JSPs for more complex UIs, and the Voyager 3.1 ORB
allows us to communciate with COM/DCOM applications, dare I say it).
Overall, I've been very, very pleased with the JSP 1.0 implementation (in
particular Live Software's JRun implementation).
-- chris --
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Frank Starsinic
> Sent: Thursday, August 12, 1999 3:10 PM
> To: [EMAIL PROTECTED]
> Subject: JSP Techniques for limiting java within the JSP (tms)
>
>
> One issue that keeps coming up is the combination of java code
> and HTML being
> put in the same
> place, i..e., the JSP page.
>
> What techniques are people using to limit the amount of java within a JSP.
>
> I realize that the use of the Bean can do just that; allowing the use of
> <%=bean.getValue()%>
> That is clear.
>
> What are other techniques that are being used to help the JSP
> developer not
> worry about the back end. Are Beans being designed in a
> particular way to
> make it easier for the JSP developer. It seems they could be and
> i'm wondering
> about any good rules of thumb, etc.
>
> Looping thru a vector of objects and then hashtables of stuff within each
> object, and having to turn it all into strings and pump it all
> thru html etc.
> can require a lot of java withing a JSP page. This is what i'd
> like to prevent
> if possible. What are other people doing here?
>
> We do Swing development and very little Web development right now
> and it seems
> to me that our Beans could/should be designed a bit differently
> if we were to
> use JSP, for instance, having all the getters return strings (to
> keep the JSP
> developer from having to convert everything to strings before
> displaying them
> on a web page, hence, cutting down on java code in the JSP)
>
> I hope this is somewhat clear...
>
> thanks,
> frank
>
>
> Craig McClanahan wrote:
>
> > Several people have asked questions about writing internationalized apps
> > with JSP. Having just done so (only with Western European languages so
> > far), I have learned some things that may be interesting to others in
> > the same situation. The basic components of my approach were as
> > follows:
> >
> > (1) All internationalized strings are stored in resource bundles
> >
> > I used property resource files named Resources.properties (the default
> > translation, which was English), and Resources_xx.properties (where "xx"
> > is the ISO code of the language), following the ResourceBundle naming
> > conventions. I heavily used the parameter replacement features like {0}
> > to synthesize internationalized messages that contained elements that
> > originated in the database.
> >
> > (2) Accessing the resource bundles from the web application
> >
> > I created a JavaBean called "BundleBean" that had a series of methods
> > with calling sequences like this:
> >
> > String message = bundleBean.getMessage(locale, "label.username");
> >
> > and it looked in the correct resource bundle for the language of this
> > locale. The bundle bean is stored in the application context in a
> > startup servlet, by calling:
> >
> > getServletContext().setAttribute("bundleBean", bundleBean);
> >
> > to make it available to both servlets and JSP pages.
> >
> > (3) Internationalize the business logic
> >
> > We had to deal with things like the fact that many European cities have
> > different names in different languages, so our business object for a
> > city has two different property getters for the name:
> >
> > String getName() returns the name in the language of the default
> > Locale
> > String getName(Locale locale) returns the name in the language of
> > the
> > specified Locale, if it is different, or in the "canonical"
> > language.
> >
> > (4) Store a Locale object for the user's preferrred language in the
> > user's session
> >
> > When a user logs on, one of the things we know is their preferred
> > language (they can switch later, if they want). To record that
> > knowledge, we store a java.util.Locale instance based on that language
> > in the session object, under key "localeBean". If the user exercizes
> > the option to change languages, we just update the locale and the next
> > page display is auto-magically done in the newly chosen language.
> >
> > (5) Separate business logic and presentation logic
> >
> > I'm a big beliver in this separation, and it paid off in this
> > application. All my form submits go to a processing servlet (in the
> > real app, it's actually an action procedure called by a single servlet)
> > that does the appropriate business logic, which is mostly independent of
> > language choice, then stores appropriate beans in the session or
> > request, and forwards to an appropriate JSP page to display the next
> > result, using RequestDispatcher.forward().
> >
> > (6) A simplified internationalized login page using the above features,
> > then, looks something like this:
> >
> > <%@ page language="java" buffer="8kb" session="true" %>
> >
> > <jsp:useBean id="attemptBean" scope="request"
> > class="com.mycompany.AttemptBean" />
> > <%-- Contains username and password from previous attempt, if any
> > --%>
> >
> > <jsp:useBean id="bundleBean" scope="application"
> > imports="java.util.Locale"
> > class="com.mycompany.BundleBean" />
> >
> > <%
> > Locale localeBean = (Locale) session.getValue("localeBean");
> > if (localeBean == null) {
> > localeBean = Locale.getDefault();
> > session.putValue("localeBean", localeBean);
> > }
> > %>
> >
> > <head>
> > <title>Logon Page</title>
> > </head>
> > <body>
> > <form action="/logon"> // Logon processing servlet
> > <table border=0>
> > <tr>
> > <th align=right>
> > <%= bundleBean.getMessage(localeBean, "label.username") %>
> >
> > </th>
> > <td>
> > <input type="text" name="username"
> > value="<%= attemptBean.getUsername() %>">
> > </td>
> > </tr>
> > <tr>
> > <th align=right>
> > <%= bundleBean.getMessage(localeBean, "label.password") %>
> >
> > </th>
> > <td>
> > <input type="password" name="password"
> > value="<%= attemptBean.getPassword() %>">
> > </td>
> > </tr>
> > <tr>
> > <td> </td>
> > <td>
> > <input type="submit" value="<%=
> > bundleBean.getMessage(localeBean, "button.LogOn") %>">
> > <input type="reset" value="<%=
> > bundleBean.getMessage(localeBean, "button.Reset") %>">
> > </td>
> > </tr>
> > </table>
> > </form>
> > </body>
> >
> > NOTE: In pages other than the login page, I use the presence or absence
> > of a Locale in the session as an indicator that the session has expired,
> > and forward control to the login page if it's missing. The logic looks
> > like this:
> >
> > <%
> > Locale localeBean = (Locale) session.getValue("localeBean");
> > if (localeBean == null) {
> > %>
> > <jsp:forward page="/login.jsp" />
> > <% } %>
> >
> > (7) Processing servlets make decisions on where to go next
> >
> > The servlet accessed by "/logon" does the following pseudocode (no
> > internationalization needed):
> > * Extract the username/password passed in the request
> > * Create an AttemptBean to store these values, and stash
> > it in the request (used to redisplay the previous input if
> > there is an error)
> > * Validate the user. If it fails, stash a bean that causes an
> > error message to be displayed (logic not shown in the JSP
> > page above), and forward to "/logon.jsp" (the page above).
> > * If validation is successful, create a Locale object with this
> > user's desired language, and stash it in the session. Then,
> > forward to "/welcome.go" (see below for what ".go" means).
> >
> > (8) Dealing with pages that really need to be written separately
> >
> > About 95% of the JSP pages in this app could be made multilingual with
> > only the need to look up message strings, as described above. However,
> > the welcome screen that is displayed after login is an example where the
> > Marketing group really wants to write custom pages in each language. We
> > established a naming convention similar to that for resource bundles,
> > creating pages named:
> >
> > /welcome_en.jsp (English)
> > /welcome_fr.jsp (French)
> > ... and so on ...
> >
> > I could have made the caller (such as the login servlet above) calculate
> > the name of the page to go to every time, but this logic would be
> > duplicated everywhere, and need to be updated every time we added a new
> > language.
> >
> > Instead, I created a clever (IMHO :-) little servlet called GoToServlet,
> > and mapped it to the ".go" filename extension. It does this:
> > * Extracts the base name passed to this call. If the login
> > servlet forwards to "/welcome.go" as above, the base name
> > (from getPathInfo(), minus the suffix) is "/welcome".
> > * Extracts the users's locale bean from the session, and gets
> > the language suffix.
> > * To the base name, append an underscore, the language code,
> > and ".jsp" to get the derived name.
> > * Forwards to that JSP page.
> >
> > This gave me the ability to very quickly forward, or create a hyperlink
> > to, a page that was really presented in separate languages with no muss
> > or fuss on the caller's part.
> >
> > None of these ideas are earth shattering, but the combination of
> > Java/Servlets/JSP makes a very powerful platform for building
> > internationalized apps.
> >
> > Craig McClanahan
> >
> >
> ==================================================================
> =========
> > To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> > of the message "signoff JSP-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
