GeeCON Prague 2014*
The moose likes JSP and the fly likes How to get rid of this scriptlet? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » JSP
Bookmark "How to get rid of this scriptlet?" Watch "How to get rid of this scriptlet?" New topic
Author

How to get rid of this scriptlet?

Thomas Kennedy
Ranch Hand

Joined: Jan 20, 2008
Posts: 137
I'm inheriting a JSP done some years ago. There is a lot of script stuff in it. A typical example:



To begin with I want to get rid of this outer Java if-else thing:

<% if (view.getUser().isSomeBoolean()) { %>

and replace it with <c:if>. So of course I have to add the jstl core declaration at the top. But after that I'm not too clear on the syntax, given that the boolean condition is not on the view bean but on an object returned by a public method on the view. Can someone clue me in here? How do I dig down to that boolean method in the context of <c:if>?

Sorry, I don't know the JSP version we're using. I'm also going to fix the getter methods -- the ones taking an argument -- because I know that's bad syntax.


Costs matter. Justice lies in processes not outcomes. Crime is caused by criminals.
Hebert Coelho
Ranch Hand

Joined: Jul 14, 2010
Posts: 754

You will have to do a hard work of writting Servlets classes and refactoring the JSP.

It will be a hard work, but it will be worth of it.


[uaiHebert.com] [Full WebApplication JSF EJB JPA JAAS with source code to download] One Table Per SubClass [Web/JSF]
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

The first line, the jsp:useBean, declares that "view" is the name of a request attribute, correct? The EL treats request attributes, and in fact everything it gets hold of, as if they were written using the Java Bean conventions. So a "getUser()" method corresponds to a "user" property, and an "isSomeBoolean()" method corresponds to a "someBoolean" property. Therefore your first line translates into

Although... there's an else clause so you would be better off with c:choose followed by c:when with that test and then c:otherwise.

As for the "getFromDos(i)" issue you identified, you're right, that is hard to address in EL. (Maybe even impossible, I don't know.) The easiest way to address it is to produce a "getFromDos()" method which returns the underlying array, or list, or whatever it is. You can then iterate through that array or list with <c:forEach>.

Oh... but then I see you've got "getProgram(i)" and "getSomeString(i)". Parallel arrays. So yeah, the data design would need to be strengthened a bit, so that you have something which returns a list of objects, each of which has a "getFromDos()" method and a "getToDos()" method and a "getProgram()" method and a "getSomeString()" method. Like Hebert said, there's some groundwork to be done there.

Thomas Kennedy
Ranch Hand

Joined: Jan 20, 2008
Posts: 137
Very interesting, thank you. I'm beginning to understand that if I get rid of those parallel arrays and replace them with an ArrayList of, say, MyResponseDataRow types, I could then for-each my way through that collection and drop all the indexing. A lot of work, indeed, but these parallel arrays are a nasty business.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61310
    
  66



[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
 
GeeCON Prague 2014
 
subject: How to get rid of this scriptlet?