Re: Another bright idea, make indexed work with JSTL forEach andfriends
On Sat, 4 Jan 2003, James Turner wrote: Date: Sat, 4 Jan 2003 13:26:34 -0500 From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Another bright idea, make indexed work with JSTL forEach and friends As has been pointed out, about the only remaining reason to use logic:iterate over c:forEach is that you can't use an html:text tag (or friends) with an indexed property set, because it only looks for logic:iterate on the page stack. Now, it would be very simple (having peered at the source) to have the html tags also look for JSTL iterators. However, to make this work, we'd need to add a dependency on jakarta-taglibs so that the class would be available. I don't think that this would break anything in terms of JSP version support, since it wouldn't require evaluation of ELs, just looking up the stack to see if we find a JSTL interator hanging around. Unless you can do this all with reflection (instead of instanceof and direct method calls), you'll create NoClassDefFound errors for people who don't have the JSTL library in the stack. Other than that caution, I'm +1. Opinions? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another bright idea, make indexed work with JSTL forEach andfriends
On Sat, 4 Jan 2003, James Turner wrote: As has been pointed out, about the only remaining reason to use logic:iterate over c:forEach is that you can't use an html:text tag (or friends) with an indexed property set, because it only looks for logic:iterate on the page stack. Now, it would be very simple (having peered at the source) to have the html tags also look for JSTL iterators. However, to make this work, we'd need to add a dependency on jakarta-taglibs so that the class would be available. I don't think that this would break anything in terms of JSP version support, since it wouldn't require evaluation of ELs, just looking up the stack to see if we find a JSTL interator hanging around. Opinions? If you want to do this, I'd rather see it happen in the html-el taglib than the regular html taglib. Struts-EL already depends on JSTL, and is designed to work in cooperation with it, so it's a much more natural fit than trying to sneak JSTL functionality into the regular tags. -- Martin Cooper _ James ICQ#: 8239923 More ways to contact me: http://wwp.icq.com/8239923 See more about me: http://web.icq.com/whitepages/about_me?Uin=8239923 _ -- 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]
Re: Another bright idea, make indexed work with JSTL forEach andfriends
On 4 Jan 2003, David M. Karr wrote: Can anyone envision any other situations in the Struts code where indirect references to the JSTL would be convenient? That, at least, could give us some additional perspective on this. General purpose access to the EL evaluator (which David used in implementing the EL-ized versions of the Struts tag libraries) would definitely be useful in general purpose computing environments. The Jelly project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing the scripting environment that Jelly supports, for example. It would be interesting to contemplate where you might usefully leverage EL expressions ... say, in struts-config.xml constructs ... Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Another bright idea, make indexed work with JSTL forEach andfriends
On Sat, 4 Jan 2003, James Turner wrote:
On Sat, 4 Jan 2003, Martin Cooper wrote:
If you want to do this, I'd rather see it happen in the html-el taglib
than the regular html taglib. Struts-EL already depends on
JSTL, and is
designed to work in cooperation with it, so it's a much more
natural fit
than trying to sneak JSTL functionality into the regular tags.
I mildly disagree. EL is to allow struts HTML tags to use EL syntax.
Yes. And why would you want to do that? Because you're already using JSTL
tags in your pages, and you want the two to work together.
This deals with letting the standard tags find JSTL looping constructs.
Yes. And why would you want to do that? Because you're already using JSTL
tags in your pages, and you want the two to work together.
Notice the remarkable similarity in the two reasons for using these pieces
of functionality? ;-)
That's why I think your suggestion fits much better in Struts-EL than in
the Struts core. Once we require Servlets 2.3 / JSP 1.2 for Struts, then
I'm all for having this in the core, along with the rest of Struts-EL.
Prior to that, I just don't like the idea of muddying the core html taglib
with references to JSTL, especially when you have to do it all through
reflection.
--
Martin Cooper
As is, you can *almost* entirely eliminate all the Struts tags except
for the HTML tags in favor of JSTL substitutes, since only the HTML tags
deal with things like actions. By implementing this, we can eliminate
having to use the logic taglibs at all. And the change is pretty darn
innocuous, here's the revisted code from BaseHandlerTag, which works
very nicely. Note that I'm not even referencing org.apache stuff. And
the JSTL stuff is only ever invoked if it fails to find the Iterate tag.
One thing I'm considering is caching the classes and methods so that the
reflection doesn't need to happen on every invokation.
protected void prepareIndex(StringBuffer handlers, String name)
throws JspException {
int index = 0;
boolean found = false;
// look for outer iterate tag
IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
// Look for JSTL loops
if (iterateTag == null) {
try {
Class loopClass =
Class.forName(javax.servlet.jsp.jstl.core.LoopTagSupport);
Object loopTag = findAncestorWithClass(this, loopClass);
if (loopTag != null) {
Method getStatus =
loopClass.getDeclaredMethod(getLoopStatus,
null);
Object status = getStatus.invoke(loopTag, null);
Class statusClass =
Class.forName(javax.servlet.jsp.jstl.core.LoopTagStatus);
Method getIndex =
statusClass.getDeclaredMethod(getIndex, null);
Integer ind = (Integer) getIndex.invoke(status,
null);
index = ind.intValue();
found = true;
}
}
catch (ClassNotFoundException ex) {}
catch (NoSuchMethodException ex) {}
catch (IllegalAccessException ex) {}
catch (IllegalArgumentException ex) {}
catch (InvocationTargetException ex) {}
catch (NullPointerException ex) {}
catch (ExceptionInInitializerError ex) {}
} else {
index = iterateTag.getIndex();
found = true;
}
if (!found) {
// this tag should only be nested in iteratetag, if it's
not, throw exception
JspException e = new
JspException(messages.getMessage(indexed.noEnclosingIterate));
RequestUtils.saveException(pageContext, e);
throw e;
}
if (name != null)
handlers.append(name);
handlers.append([);
handlers.append(index);
handlers.append(]);
if (name != null)
handlers.append(.);
}
--
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]
RE: Another bright idea, make indexed work with JSTL forEach andfriends
On Sat, 4 Jan 2003, James Turner wrote:
Ok, here's a more practical reason to do it in the base release...
The Struts-EL package doesn't handle the indexed tag at all, it relies
on the fact that it extends the org.apache.struts.taglib.html versions
of the tags which in turn eventually extend BaseHandlerTag. So, to
implement it in Struts-EL, I'll have to more prepareIndex all the way up
into the Struts-EL class (duplicated the code or wrapping it), and
change all the Struts-EL classes to extend that class instead. This
means implementing several dozen new classes in Struts-EL to avoid
extending one method in the base Struts release.
Sigh. OK, OK.
But three changes I'd like to see in the code you posted earlier:
1) Instead of calling Class.forName(), you should use
RequestUtils.applicationClass(), to make sure the context class loader is
tried first.
2) Empty catch clauses are evil. ;-) You should at least log a debug
message so that real problems can be debugged more easily.
3) Always use braces with if clauses. I know the code has plenty of cases
where that isn't done, but it's good practice to do that. I seem to recall
Craig admitting that he should have done that in the original code base.
;-)
--
Martin Cooper
James
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 04, 2003 4:37 PM
To: Struts Developers List
Subject: RE: Another bright idea, make indexed work with
JSTL forEach and friends
On Sat, 4 Jan 2003, James Turner wrote:
On Sat, 4 Jan 2003, Martin Cooper wrote:
If you want to do this, I'd rather see it happen in the
html-el taglib
than the regular html taglib. Struts-EL already depends on
JSTL, and is
designed to work in cooperation with it, so it's a much more
natural fit
than trying to sneak JSTL functionality into the regular tags.
I mildly disagree. EL is to allow struts HTML tags to use
EL syntax.
Yes. And why would you want to do that? Because you're
already using JSTL
tags in your pages, and you want the two to work together.
This deals with letting the standard tags find JSTL looping
constructs.
Yes. And why would you want to do that? Because you're
already using JSTL
tags in your pages, and you want the two to work together.
Notice the remarkable similarity in the two reasons for using
these pieces
of functionality? ;-)
That's why I think your suggestion fits much better in
Struts-EL than in
the Struts core. Once we require Servlets 2.3 / JSP 1.2 for
Struts, then
I'm all for having this in the core, along with the rest of Struts-EL.
Prior to that, I just don't like the idea of muddying the
core html taglib
with references to JSTL, especially when you have to do it all through
reflection.
--
Martin Cooper
As is, you can *almost* entirely eliminate all the Struts
tags except
for the HTML tags in favor of JSTL substitutes, since only
the HTML tags
deal with things like actions. By implementing this, we
can eliminate
having to use the logic taglibs at all. And the change is
pretty darn
innocuous, here's the revisted code from BaseHandlerTag, which works
very nicely. Note that I'm not even referencing org.apache
stuff. And
the JSTL stuff is only ever invoked if it fails to find the
Iterate tag.
One thing I'm considering is caching the classes and
methods so that the
reflection doesn't need to happen on every invokation.
protected void prepareIndex(StringBuffer handlers, String name)
throws JspException {
int index = 0;
boolean found = false;
// look for outer iterate tag
IterateTag iterateTag = (IterateTag)
findAncestorWithClass(this,
IterateTag.class);
// Look for JSTL loops
if (iterateTag == null) {
try {
Class loopClass =
Class.forName(javax.servlet.jsp.jstl.core.LoopTagSupport);
Object loopTag = findAncestorWithClass(this, loopClass);
if (loopTag != null) {
Method getStatus =
loopClass.getDeclaredMethod(getLoopStatus,
null);
Object status = getStatus.invoke(loopTag, null);
Class statusClass =
Class.forName(javax.servlet.jsp.jstl.core.LoopTagStatus);
Method getIndex =
statusClass.getDeclaredMethod(getIndex, null);
Integer ind = (Integer) getIndex.invoke(status,
null);
index = ind.intValue();
found = true;
}
}
catch (ClassNotFoundException ex) {}
catch (NoSuchMethodException ex) {}
catch (IllegalAccessException ex) {}
catch (IllegalArgumentException ex) {}
catch (InvocationTargetException ex) {}
catch (NullPointerException ex) {}
catch (ExceptionInInitializerError ex) {}
} else
RE: Another bright idea, make indexed work with JSTL forEach andfriends
On Sat, 4 Jan 2003, James Turner wrote: From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sigh. OK, OK. But three changes I'd like to see in the code you posted earlier: 1) Instead of calling Class.forName(), you should use RequestUtils.applicationClass(), to make sure the context class loader is tried first. I'll do dat. 2) Empty catch clauses are evil. ;-) You should at least log a debug message so that real problems can be debugged more easily. Well, two of them shouldn't log anything because they are simply there to catch the you haven't got JSTL case, I though about logging the other cases but they should never happen (famous last words #43456), since it would require there to be a loopTag that couldn't handle being sent the messages it defines in the Interface, but I guess I can throw in some logging If It Makes You Feel Good :-) It would make me feel so good - thank you. ;-) One case I'm thinking about here is when someone finds that it's not working for them, and they *think* they have JSTL, but it's not being picked up for some reason. A log message would tell them that Struts tried to do what they wanted, but something went wrong, hopefully helping them determine that there might be something wrong with their web app config. -- Martin Cooper 3) Always use braces with if clauses. I know the code has plenty of cases where that isn't done, but it's good practice to do that. I seem to recall Craig admitting that he should have done that in the original code base. I usually do it to, except when my old c-habits sneak in. James -- 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]
Re: Another bright idea, make indexed work with JSTL forEach andfriends
On 4 Jan 2003, David M. Karr wrote: Date: 04 Jan 2003 17:28:58 -0800 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Another bright idea, make indexed work with JSTL forEach and friends Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 4 Jan 2003, David M. Karr wrote: Can anyone envision any other situations in the Struts code where indirect references to the JSTL would be convenient? That, at least, could give us some additional perspective on this. Craig General purpose access to the EL evaluator (which David used in Craig implementing the EL-ized versions of the Struts tag libraries) would Craig definitely be useful in general purpose computing environments. The Jelly Craig project (in jakarta-commons-sandbox) uses this kind of thing for EL-izing Craig the scripting environment that Jelly supports, for example. Craig It would be interesting to contemplate where you might usefully leverage Craig EL expressions ... say, in struts-config.xml constructs ... Could we do this in DynaBean property value initializations? That would certainly make sense, as long as we could identify the variable context (in EL implementation terms) with which variable references should be resolved. I can't think of any other places in the config file where this would be useful (yet). At least one other place would be things like the pattern matching rules in the controller element for calculating URLs. Longer term (2.0 time frame probably), I'm playing with more interesting ideas like using Jelly scripts (or JSP pages) as Actions so you don't have to write them in Java. We also need a good high level multi-request framework, and it might be useful there in automating some of the forward and backward link references. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
