There's no reason you can't have view helper objects that are plain old
java objects.  You don't need to put all display-related code into JSPs.
If you put all logic (whether business logic or display logic) into
regular Java objects, it makes it easier to debug and unit test it.  I
prefer to make JSPs as simple as possible, and avoid using any kinds of
scriptlets.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -----Original Message-----
> From: Alex Muc [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, October 12, 2002 1:55 AM
> 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:tomcat-user-> [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]>

Reply via email to