The biggest problem with the general approach you suggest is that you are
mixing Java logic into your pages, which means you need a Java programmer
to maintain them. A much better strategy is to use a
model-view-controller (MVC) style architecture that has back-end business
logic setting up the dynamic things your page needs in request attributes
or session attributes, and then forward to the page (which can use things
like <jsp:getProperty> to grab them. An example of a framework for MVC
style development is Struts <http://jakarta.apache.org/struts>.
An additional benefit of banishing scriptlets from your pages is that the
JSP page compiler can generate better code, as well as handling bigger and
more complex pages. The general trend in modern JSP development is away
from scriptlets.
Craig McClanahan
On Sat, 12 Oct 2002, Alex Muc wrote:
> Date: Sat, 12 Oct 2002 01:54:58 -0400
> From: Alex Muc <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Defining methods in JSP pages
>
> Hi,
>
> I've been using JSPs for quite a while now and have been trying to find
> better ways to do various things. One of the features of JSPs that I
> stumbled on a while ago was the ability to define methods in JSPs and to
> be able to call those methods from within the page using Java Reflection
> mechanisms. This works relatively well (see example below), except for
> the baggage of having to do the reflection work. Alas, that is the
> price we pay for a strongly typed language.
>
> What I'm wondering is why more people don't use the declaration syntax
> as a way to define methods in pages and use those methods to abstract
> out some of the functionality they need? My answer would be that it is
> generally frowned upon (by the MVC crowd) to put logic into the JSP page
> and to a certain extent I agree. But, there are times where the logic
> code is only used to modify the display and in those cases it seems to
> me like putting that logic into a method within the JSP makes sense.
> For example, when building the title string of the page you often have
> to look up or build some sort of descriptive string from the various IDs
> of the objects that are part of the request/session to the page. It
> seems to me that doing this sort of operation is the kind of thing which
> should be within the JSP page and using methods within the JSP page seem
> to make even more sense as opposed to scriptlets. The alternatives are:
> 1) Put the "getPageTitle" method into the Model object. If the model is
> supposed to capture the data of the object then it doesn't seem to me
> like it should be cluttered with methods relevant to displaying the object.
> 2) Put the "getPageTitle" method into the Controller object. Again, if
> the controller is the driver of the business logic of the object(s) then
> it too doesn't seem like the right place for methods relevant to
> displaying the object.
>
> It seems like using methods in JSP pages is a good idea for certain
> things. It also has it's downsides, the main one that I see is that
> there is no inheritance among JSP pages. I wonder how hard this would
> be to add?
>
> Does any one have any comments about why defining methods in JSP pages
> is a good or bad idea? I would really appreciate hearing from you.
>
> Thanks for you time.
> Alex.
>
>
> ***************
> Example method in a JSP page:
> ***************
>
>
>
>
> <%@ page language="java" import="java.lang.reflect.*" %>
> <%!
> public String getTitle(HttpServletRequest request) {
> String id = request.getParameter("id");
> return "id: " + id;
> }
> %>
> <% Class c = this.getClass();
>
> // The types for the method call
> Class [] pTypes = new Class [1];
> Class hsr = Class.forName("javax.servlet.http.HttpServletRequest");
> pTypes[0] = hsr;
>
> // Get the method
> Method m = c.getMethod("getTitle", pTypes);
>
> // Build the list of parameters to the method
> Object [] params = new Object [1];
> params[0] = request;
>
> // Invoke the method and get the result
> String result = (String) m.invoke(this, params);
> %>
> Method Result: <%= result %>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
