Yeah, that thought hit me last night as well (just after I sent the
message of course:). I was thinking more about the possibility of doing
the call from some other JSP page as well.
Do you use these features? Do you have a prefered place for display
related functions (model/view/controller/other)?
Alex.
Chris Means wrote:
>Alex,
>
>Are you aware that you could simply call the method that you defined
>directly in the JSP body?
>
><%!
> public String getTitle(HttpServletRequest request) {
> String id = request.getParameter("id");
> return "id: " + id;
> }
>%>
>
><%
> String title = getTitle (request) ;
>
> out.write (title) ;
>%>
>
>-Chris
>
>
>
>>-----Original Message-----
>>From: Alex Muc [mailto:[EMAIL PROTECTED]]
>>Sent: Saturday, October 12, 2002 12: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:[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]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
