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]>