is there a way to call tags from within JSP scriptlets

[oldJet]

Hi Group,

I’ve been recently asked to maintain a legacy application with lots of
scriptlet code.
Here is the snippet that I need help with:


<%!
public void method1 (String x, String y) {
String z = method2();
doComplexStuff(x, y, z);
}
%>



method1 is being called from numerous places in this (very) large JSP
file. I need to replace the doComplexStuff() method with a custom tag
that looks something like this:

<xyz:doComplexStuffTag x="value1" y="value2" z="value3" />

Is there a way to replace the fourth line, i.e the doComplexStuff
(x,y,z) call, with the mentioned tag without breaking method1() ? Of
course I still need to continue passing the method parameters (x, y
and z) as tag attribute values.

I know I should refactor the whole thing, but this is not practical at
the moment.

Thanks for any pointers..

Jake

 

[Tom Anderson]

I?ve been recently asked to maintain a legacy application with lots of
scriptlet code. Here is the snippet that I need help with:

<%!
public void method1 (String x, String y) {
String z = method2();
doComplexStuff(x, y, z);
}
%>

method1 is being called from numerous places in this (very) large JSP
file. I need to replace the doComplexStuff() method with a custom tag
that looks something like this:

<xyz:doComplexStuffTag x="value1" y="value2" z="value3" />

Is there a way to replace the fourth line, i.e the doComplexStuff
(x,y,z) call, with the mentioned tag without breaking method1() ? Of
course I still need to continue passing the method parameters (x, y and
z) as tag attribute values.

Tags are objects, so you just throw method calls at them to bend them to
your will. Basically, you have to pretend to be a JSP container and do
(where DoComplexStuffTag is the tag handler class):

DoComplexStuffTag tag = new DoComplexStuffTag();
PageContext ctx = ...;
Tag parent = ...;
tag.setPageContext(ctx);
tag.setParent(parent);
tag.setX(x);
tag.setY(y);
tag.setZ(z);
tag.doStartTag();
tag.doEndTag();
tag.release();
JspFactory.releasePageContext(ctx);

Well, or something. Do you have access to the implementation of
DoComplexStuffTag? You're writing it, right? If so, you can figure out
what combination of doStartTag, doEndTag, perhaps doAfterBody, release,
etc you need to call. I've left out the getting of the parent tag and page
context because i have no idea how to do that off the top of my head, and
you're being paid to write this code, not me!

I've never done exactly this, but i have written tags which wrap or
subclass other tags, and that's sort of similar. You don't have to worry
about how to get the PageContext, though, because you can just pass on the
one you're given.

Also, you can wrap all that boilerplate in a callDoComplexStuffTag method
with the same signature as the current doComplexStuff. Which means you're
effectively back where you started, but with the actual functionality
factored out into a tag, about five times more code, and a warm fuzzy
enterprisey feeling.

Actually, a vastly better idea would be to factor the tag class so all the
work is done in a static method which you can make public. Like:

public class DoComplexStuffTag extends TagSupport {
private String x, y, z;
// getters + setters for x, y, z
public int doStartTag() {
start(getX(), getY(), getZ());
return Tag.SKIP_BODY;
}
public static void start(String x, String y, String z) {
// whatever
}
}

Then replace calls to doComplexStuff with calls to
DoComplexStuffTag.start. That means minimal work to do before you refactor
away the scriptlets, and a reason to keep your tag classes well-factored.

I know I should refactor the whole thing, but this is not practical at
the moment.

Funny how many programmers have that written on their gravestones.

tom

 

[Lew]

Funny how many programmers have that written on their gravestones.

Just a few more than have, "I will get around to writing unit tests soon."

I was writing a small module for my day job this week. After getting the
basic logic done I wrote unit tests. (Yes, that's backwards. I ought to
blush with shame. I also used Java interfaces and class stubs for the design
rather than UML.) The unit tests showed me that I had defined the equals()
and compareTo() methods wrong for one of the classes. The tests, in
conjunction with the debugger, showed me exactly why the wrong code failed.
In minutes the bug was fixed.

I don't exactly believe that unit tests should always come before core logic.
In practice I interleave the development of test code and core logic as I
flesh out a module. I firmly believe that unit tests must precede release to
the rest of the team. Somehow such tests always reveal that I've made a
mistake, and how to fix it. So I now write test code and core code
essentially contemporaneously.