RE: Another bright idea, make indexed work with JSTL forEach and friends
I'm coming into the thread late, so that's why I'm replying to a random
message in it...
How about adding indexName and indexProperty attributes. If indexed is
true it will use those properties to find a bean containing the current
index value. If indexed is true and those other attributes are not set,
then it defaults to the current mechanism for determining the index
value.
c:forEach var=item items=${items} varStatus=status
html:checkbox indexed=true indexName=status indexProperty=index
.../
/c:forEach
That way you don't have any direct dependency on JSTL, and it might work
with some other third-party looping tags (for whatever that's worth).
I'm not actually using JSTL yet (or Struts 1.1 for that matter) so maybe
this doesn't work, but it's a thought.
--
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: 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 {
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
Re: Another bright idea, make indexed work with JSTL forEach and friends
Craig wrote : 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. If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or sometimes design patterns) we lose OO. OO gives us productivity as Java is OO capable, and some people use it in OO way. (Similar issue in C++, some people use C++ in C mode, or what I call object disoriented mode). Unless there is a way I do not know of to make above (XML, el, generators) be able to do: - is a / has a (extends a base class, or has an extended helper object) - inheritance and delegation (same as above) allows for after the fact programing. After a developer thinks they are done with the scope, *clients like to change the scope*, so when one has a baseAction or a baseActionHelper, one can go to the base class and quickly maintain the code, and not have to go to every place. Java is OO capable, whereas above listed things AFAIK do not have that productivity in maintenance mode. Please take OO in consideration, it is a 10 fold advantage for the OO Java practitioners. (It is not just overriding and polymorphisam. I could give more real life examples. Like one base action that need to act this way or another depedning on the situation.) Same issue is for non Action cases. XML, or JSP, EL, generator, or scripts (or sometimes design patterns) we could lose OO and flexibility. (I can say in EL when you use this expresion here do it this way, BUT over here, use the same expresion in another way) (OT: I was told that Flash (when one does data entery screens in a Flash plug in) can do limited OO) .V Craig R. McClanahan wrote: 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]
Re: Another bright idea, make indexed work with JSTL forEach and friends
On Sun, 5 Jan 2003, V. Cekvenich wrote: Craig wrote : 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. If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or sometimes design patterns) we lose OO. Not necessarily. XML is more a syntax than a language - it's what you do with it that supplies the semantics. (This is part of its heritage - SGML was designed specifically to avoid embedding of semantics in the original document, which is why DSSSL was designed to provide those semantics.) For example, look at Tiles. I can create a definition in XML, and then I can create further definitions that 'extend' the first one. Just as other languages such as Java and C++ can be used for object oriented programming, XML can too. It just depends on how you use it. -- Martin Cooper OO gives us productivity as Java is OO capable, and some people use it in OO way. (Similar issue in C++, some people use C++ in C mode, or what I call object disoriented mode). Unless there is a way I do not know of to make above (XML, el, generators) be able to do: - is a / has a (extends a base class, or has an extended helper object) - inheritance and delegation (same as above) allows for after the fact programing. After a developer thinks they are done with the scope, *clients like to change the scope*, so when one has a baseAction or a baseActionHelper, one can go to the base class and quickly maintain the code, and not have to go to every place. Java is OO capable, whereas above listed things AFAIK do not have that productivity in maintenance mode. Please take OO in consideration, it is a 10 fold advantage for the OO Java practitioners. (It is not just overriding and polymorphisam. I could give more real life examples. Like one base action that need to act this way or another depedning on the situation.) Same issue is for non Action cases. XML, or JSP, EL, generator, or scripts (or sometimes design patterns) we could lose OO and flexibility. (I can say in EL when you use this expresion here do it this way, BUT over here, use the same expresion in another way) (OT: I was told that Flash (when one does data entery screens in a Flash plug in) can do limited OO) .V Craig R. McClanahan wrote: 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] -- 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 and friends
Oh. Yeah, tiles XML is OO. Thanks for the correction! .V Martin Cooper wrote: On Sun, 5 Jan 2003, V. Cekvenich wrote: Craig wrote : 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. If Actions, or anything goes XML (Jelly), or JSP, EL or generator (or sometimes design patterns) we lose OO. Not necessarily. XML is more a syntax than a language - it's what you do with it that supplies the semantics. (This is part of its heritage - SGML was designed specifically to avoid embedding of semantics in the original document, which is why DSSSL was designed to provide those semantics.) For example, look at Tiles. I can create a definition in XML, and then I can create further definitions that 'extend' the first one. Just as other languages such as Java and C++ can be used for object oriented programming, XML can too. It just depends on how you use it. -- Martin Cooper OO gives us productivity as Java is OO capable, and some people use it in OO way. (Similar issue in C++, some people use C++ in C mode, or what I call object disoriented mode). Unless there is a way I do not know of to make above (XML, el, generators) be able to do: - is a / has a (extends a base class, or has an extended helper object) - inheritance and delegation (same as above) allows for after the fact programing. After a developer thinks they are done with the scope, *clients like to change the scope*, so when one has a baseAction or a baseActionHelper, one can go to the base class and quickly maintain the code, and not have to go to every place. Java is OO capable, whereas above listed things AFAIK do not have that productivity in maintenance mode. Please take OO in consideration, it is a 10 fold advantage for the OO Java practitioners. (It is not just overriding and polymorphisam. I could give more real life examples. Like one base action that need to act this way or another depedning on the situation.) Same issue is for non Action cases. XML, or JSP, EL, generator, or scripts (or sometimes design patterns) we could lose OO and flexibility. (I can say in EL when you use this expresion here do it this way, BUT over here, use the same expresion in another way) (OT: I was told that Flash (when one does data entery screens in a Flash plug in) can do limited OO) .V Craig R. McClanahan wrote: 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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. Opinions? _ 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]
Re: Another bright idea, make indexed work with JSTL forEach and friends
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig 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. Craig Unless you can do this all with reflection (instead of instanceof and Craig direct method calls), you'll create NoClassDefFound errors for people who Craig don't have the JSTL library in the stack. Other than that caution, I'm Craig +1. That would be gnarly to try to do this with all string-based reflection (no ClassName.class references or instanceof usage). Writing a version of findAncestorWithClass that takes a string instead of a Class is the first step. You'd also have to deal with allowing subclasses of the tag types. That's probably the ugliest part. At this point, I really don't see the urgency. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- 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 and friends
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.
This deals with letting the standard tags find JSTL looping constructs.
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]
Re: Another bright idea, make indexed work with JSTL forEach and friends
James == James Turner [EMAIL PROTECTED] writes: James 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. James I mildly disagree. EL is to allow struts HTML tags to use EL syntax. James This deals with letting the standard tags find JSTL looping constructs. James As is, you can *almost* entirely eliminate all the Struts tags except James for the HTML tags in favor of JSTL substitutes, since only the HTML tags James deal with things like actions. By implementing this, we can eliminate James having to use the logic taglibs at all. And the change is pretty darn James innocuous, here's the revisted code from BaseHandlerTag, which works James very nicely. Note that I'm not even referencing org.apache stuff. And James the JSTL stuff is only ever invoked if it fails to find the Iterate tag. James One thing I'm considering is caching the classes and methods so that the James reflection doesn't need to happen on every invokation. Sigh. The balance of architectural purity with convenience. It looks like what you've implemented is about the best you can do (you should implement reflection object caching, as you mention). It directly pollutes the Struts code with references to the JSTL, albeit not at compile time. Is that a problem? Who knows? 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. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- 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 and friends
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 :-) 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]
