Re: [PATCH] Beta 1.3 pulls tag values from wrong bean
The general Bugzilla page is wrong in our case (been meaning to fix
that). We prefer that patches be attached to Bugzilla issues so that
they dont' get buried on the list =:0)
-Ted.
David Morris wrote:
I located the source of the problem, which is caused
by a change to the nested tags. The code causing the error is this block
found in the NestedPropertyHelper.getNestedNameProperty method.
The name property for any tag that extends
org.apache.struts.taglib.html.BaseFieldTag
is initialized to a constant value of
Constants.BEAN_KEY. That means the test for
null is never met so the innermost nested
tag's (which is the nested:text tag in this case)
name is used in some cases.
Removing this code should fix my case, but
I suspect that there was a reason for this
change, which was made shortly after beta 2
was released. Here is a patch that is less
drastic than the removal. This patch makes
the minimal change, but there are still cases
in the existing code where errors are not
dealt with that should probably be fixed.
The bugzilla page says to send a patch rather
to the developer list so here is one.
David Morris
Index: NestedPropertyHelper.java
===
RCS file: /home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/nested/NestedPropertyHelper.java,v
retrieving revision 1.11
diff -u -r1.11 NestedPropertyHelper.java
--- NestedPropertyHelper.java 16 Nov 2002 07:07:07 - 1.11
+++ NestedPropertyHelper.java 4 Jan 2003 07:14:13 -
@@ -65,6 +65,7 @@
import javax.servlet.jsp.tagext.Tag;
import org.apache.struts.taglib.html.FormTag;
+import org.apache.struts.taglib.html.Constants;
/** A simple helper class that does everything that needs to be done to get the
* nested tag extension to work. Knowing what tags can define the lineage of
@@ -211,11 +212,17 @@
Tag namedTag = (Tag)tag;
// see if we're already in the right location
+String defaultName = null;
if (namedTag instanceof NestedNameSupport) {
String name = ((NestedNameSupport)namedTag).getName();
- // return if we already have a name
+ // return if we already have a name and not just default
if (name != null) {
- return name;
+if (name.equals(Constants.BEAN_KEY)) {
+defaultName = name;
+}
+else {
+return name;
+}
}
}
@@ -228,7 +235,11 @@
!(namedTag instanceof NestedParentSupport) );
if (namedTag == null) {
- // need to spit some chips
+// Return default name because parent is not more specific.
+if (defaultName != null) {
+return defaultName;
+}
+// need to spit some chips
}
String nameTemp = null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Ted Husted,
Struts in Action http://husted.com/struts/book.html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposed: logic:else clause
If you wrote a patch and it worked, there'd be no technical reason to veto it. But since it is a straight-line convenience enhancement, it would have to wait for Struts 1.2.x. The general feeling has been, as others have expressed, that it would be better to put development effort into libraries like Struts-el or (the upcoming) Struts-jsf, rather than then venerable logic tags. But, as a Committer, you can choose your own priorities =:0), and, as mentioned, it would be hard to find a technical reason to block such a patch. I don't know what IDE you are using, but another way to go would be to define a macro or template that filled out the equal/notEqual stuff for you. -Ted. James Turner wrote: I find in my code, I do the following a lot: logic:equal name=foo property=bar valuebaz . . . /logic:equal logic:notEqual name=foo property=bar valuebaz . . . /logic:notEqual I'd like to propose (and would be willing to code) the following: logic:equal name=foo property=bar valuebaz . . . logic:else . . . /logic:else /logic:equal What do people think? James _ 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] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Modules and path mapping (/do/*)
I decided to try to get modules to work with path-mapping tonight with no luck. I'll enter this into Bugzilla if you'd like. Basically, I have a forward that switches to the module: With extension mapping: forward name=uploadResume contextRelative=true path=/upload/index.do redirect=true / With path mapping: forward name=uploadResume contextRelative=true path=/do/upload/index redirect=true / Or at least, I think that's the logical configuration. From the logging, I get: ERROR [Thread-2] [org.apache.struts.action.RequestProcessor] RequestProcessor.processMapping(664) | Invalid path /upload /index was requested In my upload module, I have the following index forward that I'm expecting it to hit: forward name=index path=/do/index / I'm willing to try a couple hints if anyone has some. My controller does not have a pagePattern defined. Thanks, Matt
DO NOT REPLY [Bug 15799] New: - Nested tags picks up wrong bean for values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15799.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15799
Nested tags picks up wrong bean for values
Summary: Nested tags picks up wrong bean for values
Product: Struts
Version: 1.0 Beta 3
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I located the source of the problem, which is caused
by a change to the nested tags. The code causing the error is this block
found in the NestedPropertyHelper.getNestedNameProperty method.
The name property for any tag that extends
org.apache.struts.taglib.html.BaseFieldTag
is initialized to a constant value of
Constants.BEAN_KEY. That means the test for
null is never met so the innermost nested
tag's (which is the nested:text tag in this case)
name is used in some cases.
Removing this code should fix my case, but
I suspect that there was a reason for this
change, which was made shortly after beta 2
was released. Here is a patch that is less
drastic than the removal. This patch makes
the minimal change, but there are still cases
in the existing code where errors are not
dealt with that should probably be fixed.
Index: NestedPropertyHelper.java
===
RCS file: /home/cvspublic/jakarta-
struts/src/share/org/apache/struts/taglib/nested/NestedPropertyHelper.java,v
retrieving revision 1.11
diff -u -r1.11 NestedPropertyHelper.java
--- NestedPropertyHelper.java 16 Nov 2002 07:07:07 - 1.11
+++ NestedPropertyHelper.java 4 Jan 2003 07:14:13 -
@@ -65,6 +65,7 @@
import javax.servlet.jsp.tagext.Tag;
import org.apache.struts.taglib.html.FormTag;
+import org.apache.struts.taglib.html.Constants;
/** A simple helper class that does everything that needs to be done to get
the
* nested tag extension to work. Knowing what tags can define the lineage of
@@ -211,11 +212,17 @@
Tag namedTag = (Tag)tag;
// see if we're already in the right location
+String defaultName = null;
if (namedTag instanceof NestedNameSupport) {
String name = ((NestedNameSupport)namedTag).getName();
- // return if we already have a name
+ // return if we already have a name and not just default
if (name != null) {
- return name;
+if (name.equals(Constants.BEAN_KEY)) {
+defaultName = name;
+}
+else {
+return name;
+}
}
}
@@ -228,7 +235,11 @@
!(namedTag instanceof NestedParentSupport) );
if (namedTag == null) {
- // need to spit some chips
+// Return default name because parent is not more specific.
+if (defaultName != null) {
+return defaultName;
+}
+// need to spit some chips
}
String nameTemp = null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Comment RE: Bug 11932
I was poking around the comments for this bug when I noticed the following passage: This method no longer deals with message resources. In 1.1 b2 it puts the correct message resource for a sub-app in the request. However, it was not dealing with possible bundle keys. Is there a benifit that results form taking the correct message resources from the servlet context and putting them in the request? I could not think of any so I removed all the code from this method that deals with MessageResources objects (the last 7 lines). I want to mention a scenario when I might want to have the MesssageResources stored in the Request... We are writing a hosted application that can have client-specific resource mappings (e.g. logos). One possible solution would be to pre-process the request looking for the client ID in the session (it gets put there during login) and figure out which MessageResources should be placed into the Request. This could not be done seemlessly in Stuts 1.0 because the framework would *always* look in the application context for the MessageResources so there was no way for me to handle multiple customizations within a single app context. By extending the framework (specifically RequestUtils.getMessage) to look in the request for overrides, I now had a way to interpose my overrides without having to change any of the existing framework (e.g. I could use the existing taglibs instead of writing my own to call my own version of RequestUtils.getMessage). This, of course, presumes that you guys would have been willing to commit to this implicit context as a public interface. I realize what I'm doing would have to be done carefully to make sure I don't break other assumptions but it seems like a resonably elegant way to solve my problem. BTW (I know I might get smacked for asking this question in this forum) if anyone has a suggestion for an alternative solution to my problem I'm all ears (but send it to me privately so I don't get into REALLY big trouble for my first posting! :-) -- 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 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 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 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]
Message Resource is not multi-app aware (was: Comment RE: Bug 11932)
[ Forgive the re-post I wanted to give this a more meaningfull subject. ] I was poking around the comments for this bug when I noticed the following passage: This method no longer deals with message resources. In 1.1 b2 it puts the correct message resource for a sub-app in the request. However, it was not dealing with possible bundle keys. Is there a benifit that results form taking the correct message resources from the servlet context and putting them in the request? I could not think of any so I removed all the code from this method that deals with MessageResources objects (the last 7 lines). I want to mention a scenario when I might want to have the MesssageResources stored in the Request... We are writing a hosted application that can have client-specific resource mappings (e.g. logos). One possible solution would be to pre-process the request looking for the client ID in the session (it gets put there during login) and figure out which MessageResources should be placed into the Request. This could not be done seemlessly in Stuts 1.0 because the framework would *always* look in the application context for the MessageResources so there was no way for me to handle multiple customizations within a single app context. By extending the framework (specifically RequestUtils.getMessage) to look in the request for overrides, I now had a way to interpose my overrides without having to change any of the existing framework (e.g. I could use the existing taglibs instead of writing my own to call my own version of RequestUtils.getMessage). This, of course, presumes that you guys would have been willing to commit to this implicit context as a public interface. I realize what I'm doing would have to be done carefully to make sure I don't break other assumptions but it seems like a resonably elegant way to solve my problem. BTW (I know I might get smacked for asking this question in this forum) if anyone has a suggestion for an alternative solution to my problem I'm all ears (but send it to me privately so I don't get into REALLY big trouble for my first posting! :-) -- 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: Modules and path mapping (/do/*)
Something I've been meaning to try is to actual define the module as /do/$MODULE, but I don't have any open projects that use modules to try this with =:( -T. Matt Raible wrote: I decided to try to get modules to work with path-mapping tonight with no luck. I'll enter this into Bugzilla if you'd like. Basically, I have a forward that switches to the module: With extension mapping: forward name=uploadResume contextRelative=true path=/upload/index.do redirect=true / With path mapping: forward name=uploadResume contextRelative=true path=/do/upload/index redirect=true / Or at least, I think that's the logical configuration. From the logging, I get: ERROR [Thread-2] [org.apache.struts.action.RequestProcessor] RequestProcessor.processMapping(664) | Invalid path /upload /index was requested In my upload module, I have the following index forward that I'm expecting it to hit: forward name=index path=/do/index / I'm willing to try a couple hints if anyone has some. My controller does not have a pagePattern defined. Thanks, Matt -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tag Elimination
The html tags are useful struts tags in a standard browser environment. The nested iterators, since they iteract nicely with html tags, seem more straight forward to use than the equivalent JSTL. If you are already iterating using the nested taglib, the nested logic tags are again more straightforward to use than the equivalent jstl tags. If the jstl tags could be used easily as the iterating library for the html tags, it would be a nice benefit for those who use form nesting. Edgar 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
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 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]
cvs commit: jakarta-struts/doc/resources powered.xml
martinc 2003/01/04 14:15:10
Modified:.build.xml
doc/resources powered.xml
Log:
Add Benefit Systems to the Powered By page.
PR: 15753
Submitted by: James Turner
Revision ChangesPath
1.89 +25 -0 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.88
retrieving revision 1.89
diff -u -r1.88 -r1.89
--- build.xml 30 Dec 2002 08:52:50 - 1.88
+++ build.xml 4 Jan 2003 22:15:10 - 1.89
@@ -832,6 +832,31 @@
/target
+
+
+
+
+target name=checkSource
+description=Checks source code against coding guidelines
+depends=init
+taskdef name=checkstyle
+ classname=com.puppycrawl.tools.checkstyle.CheckStyleTask
+ classpath=${checkstyle.classpath} /
+checkstyle properties=${shared.java.dir}/Config/checkstyle.properties
+headerFile=${shared.java.dir}/Config/checkstyle.header
+formatter type=plain/
+fileset dir=${basedir} includes=**/*.java/
+/checkstyle
+/target
+
+
+
+
+
+
+
+
+
!--
Run tests on all servers not commented out in the build.properties file.
--
1.11 +1 -0 jakarta-struts/doc/resources/powered.xml
Index: powered.xml
===
RCS file: /home/cvs/jakarta-struts/doc/resources/powered.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- powered.xml 25 Dec 2002 06:25:04 - 1.10
+++ powered.xml 4 Jan 2003 22:15:10 - 1.11
@@ -17,6 +17,7 @@
!-- MISSING CREDIT 6/25/02 --pa
href=http://www.application-servers.com/;bApplication-Servers.com/b/a - French
site./p
pa href=http://amalregistry.webhop.org/;bAlaskan Malamute
Registry/b/a/p
pa href=http://www.basebeans.com/;bbaseBeans Engineering/b/a/p
+pa href=https://secure.benefit-systems.com/benefit/bsi/;bBenefit Systems,
Inc./b/a/p
pa href=http://www.bug-track.com/;bBug-Track.com/b/a/p
!-- HTTP [500] 6/25/02 --pa
href=http://www.clickstarttutoring.com/index.jsp;bClickstart Tutoring/b/a -
One on one in home tutoring./p
!-- MISSING CREDIT 6/25/02 --pa href=http://dbforms.org/;bdbForms/b/a
- RAD framework for database applications./p
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15753] - Add powered by entry
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15753. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15753 Add powered by entry [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-04 22:16 --- Fixed in the 20030105 nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Action Chaining
There is a new URL for my Struts Action Chaining package. http://www.strutschaining.org/ Thanks for all of your feedback! Karl - Original Message - From: Karl Baum [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, December 30, 2002 11:07 PM Subject: Struts Action Chaining Some time ago I emailed the developers list with the idea of an Action which chained other Action's together based on Locale. I have implemented the idea and posted the results on the web along with some documentation: http://kbaum.freewebsitehosting.com/doc/ Please take a look and let me know what you think. Thanks. Karl -- 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]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/logic MessagesPresentTag.java
martinc 2003/01/04 16:40:04 Modified:src/share/org/apache/struts/config ConfigHelperInterface.java src/share/org/apache/struts/taglib/bean MessageTag.java src/share/org/apache/struts/taglib/html FormTag.java src/share/org/apache/struts/taglib/logic MessagesPresentTag.java Log: Fix duplicate imports and unused imports. Revision ChangesPath 1.5 +4 -7 jakarta-struts/src/share/org/apache/struts/config/ConfigHelperInterface.java Index: ConfigHelperInterface.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/config/ConfigHelperInterface.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ConfigHelperInterface.java12 Nov 2002 03:56:09 - 1.4 +++ ConfigHelperInterface.java5 Jan 2003 00:40:04 - 1.5 @@ -80,9 +80,6 @@ import org.apache.struts.upload.MultipartRequestWrapper; import org.apache.struts.util.MessageResources; -// since 1.1 -import org.apache.struts.action.ActionMessages; - /** * NOTE: THIS CLASS IS UNDER ACTIVE DEVELOPMENT. 1.9 +4 -5 jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java Index: MessageTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/MessageTag.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- MessageTag.java 12 Nov 2002 03:56:08 - 1.8 +++ MessageTag.java 5 Jan 2003 00:40:04 - 1.9 @@ -69,7 +69,6 @@ import javax.servlet.jsp.tagext.TagSupport; import org.apache.struts.Globals; -import org.apache.struts.action.Action; import org.apache.struts.util.MessageResources; import org.apache.struts.util.RequestUtils; import org.apache.struts.util.ResponseUtils; 1.42 +4 -5 jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java Index: FormTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- FormTag.java 29 Dec 2002 17:00:15 - 1.41 +++ FormTag.java 5 Jan 2003 00:40:04 - 1.42 @@ -62,7 +62,6 @@ package org.apache.struts.taglib.html; import java.io.IOException; -import java.util.StringTokenizer; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; 1.6 +1 -2 jakarta-struts/src/share/org/apache/struts/taglib/logic/MessagesPresentTag.java Index: MessagesPresentTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/MessagesPresentTag.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- MessagesPresentTag.java 12 Nov 2002 03:56:10 - 1.5 +++ MessagesPresentTag.java 5 Jan 2003 00:40:04 - 1.6 @@ -61,7 +61,6 @@ import javax.servlet.jsp.JspException; import org.apache.struts.Globals; -import org.apache.struts.action.Action; import org.apache.struts.action.ActionMessages; import org.apache.struts.util.RequestUtils; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposed: logic:else clause
It looks like you're a committer now (congratulations!) so you could do this if you wanted. I think it's a waste of time because you can just use the JSTL. Dave From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Proposed: logic:else clause Date: Fri, 3 Jan 2003 16:44:09 -0500 I find in my code, I do the following a lot: logic:equal name=foo property=bar valuebaz . . . /logic:equal logic:notEqual name=foo property=bar valuebaz . . . /logic:notEqual I'd like to propose (and would be willing to code) the following: logic:equal name=foo property=bar valuebaz . . . logic:else . . . /logic:else /logic:equal What do people think? James _ 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] _ The new MSN 8 is here: Try it free* for 2 months http://join.msn.com/?page=dept/dialup -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Proposed: logic:else clause
I think I'll pass, I've decided to make the (Struts) world safe for JSTL instead. :-) James -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 8:03 PM To: [EMAIL PROTECTED] Subject: Re: Proposed: logic:else clause It looks like you're a committer now (congratulations!) so you could do this if you wanted. I think it's a waste of time because you can just use the JSTL. Dave From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Proposed: logic:else clause Date: Fri, 3 Jan 2003 16:44:09 -0500 I find in my code, I do the following a lot: logic:equal name=foo property=bar valuebaz . . . /logic:equal logic:notEqual name=foo property=bar valuebaz . . . /logic:notEqual I'd like to propose (and would be willing to code) the following: logic:equal name=foo property=bar valuebaz . . . logic:else . . . /logic:else /logic:equal What do people think? James _ 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] _ The new MSN 8 is here: Try it free* for 2 months http://join.msn.com/?page=dept/dialup -- To unsubscribe, e-mail: mailto:struts-dev- [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
cvs commit: jakarta-struts/src/share/org/apache/struts/tiles/actions NoOpAction.java ReloadDefinitionsAction.java ViewDefinitionsAction.java
martinc 2003/01/04 17:24:48 Modified:src/share/org/apache/struts/tiles ActionComponentServlet.java ActionController.java ComponentDefinitionsFactory.java DefinitionAttribute.java DefinitionNameAttribute.java DefinitionsUtil.java DirectStringAttribute.java PathAttribute.java TilesPlugin.java TilesUtilStrutsImpl.java TilesUtilStrutsModulesImpl.java src/share/org/apache/struts/tiles/actions NoOpAction.java ReloadDefinitionsAction.java ViewDefinitionsAction.java Log: Fix remaining unused imports. I think I've nailed them all now. Revision ChangesPath 1.7 +3 -4 jakarta-struts/src/share/org/apache/struts/tiles/ActionComponentServlet.java Index: ActionComponentServlet.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/ActionComponentServlet.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- ActionComponentServlet.java 17 Dec 2002 00:57:36 - 1.6 +++ ActionComponentServlet.java 5 Jan 2003 01:24:48 - 1.7 @@ -76,7 +76,6 @@ import org.apache.struts.action.ActionServlet; import org.apache.struts.taglib.html.Constants; import org.apache.struts.upload.MultipartRequestWrapper; -import org.apache.struts.util.RequestUtils; /** * Action Servlet to be used with Tiles and Struts 1.0.x. 1.2 +3 -4 jakarta-struts/src/share/org/apache/struts/tiles/ActionController.java Index: ActionController.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/ActionController.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ActionController.java 25 Jun 2002 03:14:49 - 1.1 +++ ActionController.java 5 Jan 2003 01:24:48 - 1.2 @@ -63,7 +63,6 @@ package org.apache.struts.tiles; import org.apache.struts.action.Action; -import org.apache.struts.action.ActionServlet; import java.io.IOException; import javax.servlet.http.HttpServletRequest; 1.3 +3 -4 jakarta-struts/src/share/org/apache/struts/tiles/ComponentDefinitionsFactory.java Index: ComponentDefinitionsFactory.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/ComponentDefinitionsFactory.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ComponentDefinitionsFactory.java 15 Jul 2002 12:51:52 - 1.2 +++ ComponentDefinitionsFactory.java 5 Jan 2003 01:24:48 - 1.3 @@ -64,7 +64,6 @@ import java.util.Map; import java.io.Serializable; -import javax.servlet.jsp.PageContext; import javax.servlet.ServletRequest; import javax.servlet.ServletContext; 1.2 +3 -8 jakarta-struts/src/share/org/apache/struts/tiles/DefinitionAttribute.java Index: DefinitionAttribute.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/DefinitionAttribute.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- DefinitionAttribute.java 25 Jun 2002 03:14:49 - 1.1 +++ DefinitionAttribute.java 5 Jan 2003 01:24:48 - 1.2 @@ -62,11 +62,6 @@ package org.apache.struts.tiles; -import javax.servlet.jsp.PageContext; -import javax.servlet.jsp.JspException; -import javax.servlet.ServletException; -import java.io.IOException; - /** * Attribute representing a Component Definition. * This attribute definition contains a Component definition. 1.2 +3 -8 jakarta-struts/src/share/org/apache/struts/tiles/DefinitionNameAttribute.java Index: DefinitionNameAttribute.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/DefinitionNameAttribute.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- DefinitionNameAttribute.java 25 Jun 2002 03:14:49 - 1.1 +++ DefinitionNameAttribute.java 5 Jan 2003 01:24:48 - 1.2 @@ -62,11 +62,6 @@ package org.apache.struts.tiles; -import javax.servlet.jsp.PageContext; -import javax.servlet.jsp.JspException; -import javax.servlet.ServletException; -import java.io.IOException; - /** * Component attribute. * Such attribute value represent an instance name. 1.10 +3 -4
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]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html BaseHandlerTag.java
martinc 2003/01/04 17:40:44 Modified:src/share/org/apache/struts/taglib/html BaseHandlerTag.java Log: Ack! Fix one more (newly added!) unused import. Revision ChangesPath 1.22 +4 -5 jakarta-struts/src/share/org/apache/struts/taglib/html/BaseHandlerTag.java Index: BaseHandlerTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/BaseHandlerTag.java,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- BaseHandlerTag.java 5 Jan 2003 00:50:08 - 1.21 +++ BaseHandlerTag.java 5 Jan 2003 01:40:44 - 1.22 @@ -65,7 +65,6 @@ import javax.servlet.jsp.JspException; import javax.servlet.jsp.tagext.BodyTagSupport; -import javax.servlet.jsp.tagext.Tag; import org.apache.struts.Globals; import org.apache.struts.taglib.logic.IterateTag; -- 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: 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]
cvs commit: jakarta-struts build.properties.sample build.xml
martinc 2003/01/04 18:48:22
Modified:.build.properties.sample build.xml
Log:
Add new tasks for running Checkstyle and PMD, if available. If the tools
are not available, the tasks do nothing.
Revision ChangesPath
1.24 +12 -1 jakarta-struts/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-struts/build.properties.sample,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- build.properties.sample 29 Dec 2002 20:54:15 - 1.23
+++ build.properties.sample 5 Jan 2003 02:48:21 - 1.24
@@ -95,6 +95,17 @@
# going to execute the deploy.catalina target.
xerces.jar=${apache.home}/xerces-1_4_4/xerces.jar
+# Properties related to optional tasks
+#
+
+# The JAR file containing the Checkstyle package version 2.4, if available. If
+# you do not have Checkstyle installed, do not set this property.
+checkstyle.jar = /Java/checkstyle-2.4/checkstyle-all-2.4.jar
+
+# The JAR file containing the PMD package version 1.01, if available. If
+# you do not have PMD installed, do not set this property.
+pmd.jar = /Java/pmd/lib/pmd-1.01.jar
+
# Properties related to Struts Contrib
# -
1.91 +30 -0 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- build.xml 4 Jan 2003 22:22:24 - 1.90
+++ build.xml 5 Jan 2003 02:48:21 - 1.91
@@ -745,6 +745,36 @@
!--
+Source code analysis targets
+--
+target name=checkstyle if=checkstyle.jar
+description=Checks source code against Sun coding guidelines
+depends=init
+taskdef name=checkstyle
+ classname=com.puppycrawl.tools.checkstyle.CheckStyleTask
+classpath location=${checkstyle.jar}/
+/taskdef
+checkstyle
+formatter type=plain/
+fileset dir=${src.share.dir} includes=**/*.java/
+/checkstyle
+/target
+
+target name=pmd if=pmd.jar
+description=Locates unused imports, unused variables, etc.
+depends=init
+taskdef name=pmd
+ classname=net.sourceforge.pmd.ant.PMDTask
+classpath location=${pmd.jar}/
+/taskdef
+pmd reportFile=pmdreport.html format=html
+ rulesetfiles=rulesets/unusedcode.xml,rulesets/imports.xml
+fileset dir=${src.share.dir} includes=**/*.java/
+/pmd
+/target
+
+
+!--
Compile Website documenation
--
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts commit access
Karma granted. Welcome aboard James! Craig On Sat, 4 Jan 2003, James Turner wrote: Date: Sat, 4 Jan 2003 18:42:59 -0500 From: James Turner [EMAIL PROTECTED] Reply-To: Jakarta Project Management Committee List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts commit access Results of the vote for me to be added as a Struts committer: Martin Cooper [[EMAIL PROTECTED]] +1 Cedric Dumoulin [[EMAIL PROTECTED]] +1 Ted Husted [[EMAIL PROTECTED]] +1 James Mitchell [[EMAIL PROTECTED]] +1 Craig R. McClanahan [[EMAIL PROTECTED]] +1 Eddie Bush [[EMAIL PROTECTED]] +1 No -1 votes. I already have an account as a Commons committer Thanks, James _ 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 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]
Struts Version 2 Proposal - Workflow and extra
Dear Struts Commiters, I know that the current focus is on finalizing Struts 1.1, but I would like to propose a design for version 2.0. I have taken the commons-workflow package and built on top of it a package which I have been calling PageFlow. The modifications Ive made basically webify the workflow package and make it more conceptually sound for building and maintaining large web applications. PageFlow provides a significant feature-set enhancement over the current Struts application controller. Some of the improvement is based on the features of the commons-workflow and some of I have added. I have not really attempted to improve the building of the pages themselves, just the controller piece. Id like your input on getting the design and code out there for evaluation. I am at the prototype level and having just come off a large Struts application, I know this package would really push the Struts forward. Unfortunately, the code is not built into the current contrib structure so putting it there would make the build difficult. There is still a significant amount of code documentation to complete etc. This is completely prototype code so the edges are a little (read very) rough. The most significant features are: Contextual Pages and Actions: Page flows are logically grouped sets of pages connected by actions. Actions are declared between pages and are made up of one or more steps. In other words they are little workflows. In fact the page flow is the central metaphor for the framework. For example, the developer declares a page in the struts-config file (what is called a forward right now) and then uses an instance of that page in a pageflow. The benefit to the developer is that a JSP may be re-used in different ways at different points in the applicaiton. That means the inside a page-flow a developer may use a page with a different form, different actions, etc. For example, in a recent Struts application, I had numerous places from which could reach an edit screen. This screen had to have a large logic:if block for its submit button (since we needed different action objects, parameters, etc depending on where we came from). In pageflow the actions are based on the users location in the context, so all pages and actions are contextual. Workflow: The workflow features of PageFlow are much like those of the commons-workflow. An action is composed of steps. These steps can be custom written by the developer, though I have a significant number of re-usable actions already defined. This concept is perfect for re-use. I have steps to call other workflow systems (BEA BPM, Commons-Workflow, Tibco BusinessWorks, etc), web services, print log statements, call session beans and a host of others can be written later. These re-usable steps will reduce the actual code on web apps dramatically. Mult-Level Wizards and PageFlows: Page flows are able to be nested at any level of depth and may be called from other actions with parameters. As all of the activities in a web application are housed in a page flow this makes generating a wizard or a re-usable application trivial. For example, a developer could create an add/edit/delete pageflow and then pass in the variable (entity bean, jdo, custom data object) to be added/edited/deleted as well as custom tiles declarations so the appropriate pages would pop-up. A wizard is even simpler. Any of these pageflow may also nest other pageflow while still sharing data through the session and application scopes or through parameters. Events: All of the commons-workflow events are fired. I have also added web applicaiton specific events like navigation events, form object events, action events, scope modifier events, application load and destroyed events, etc. This makes it easy to execute logic based on the users context or very complex combinations of events (add an event listener so that anytime a user goes to the resume it will check if they used the name Tom in the session.username variable, etc.) The user may add an event listener by adding a step to the xml pageflow declaration. Macro MVC: currently Struts supports page-level MVC. That is, the model object is represented by the form, the view by the page, and the Struts Request Processor is the controller. I have kept this intact in PageFlow, but have added declarative memory management (via decalaring and using variables in the struts-config.xml and pageflow-config.xml files) and allowed objects in these scopes to be assigned and converted to/from form variables. This allows the developer to use and modify objects in memory without writing any java code. I call it Macro MVC because the variables are made higher level model objects which provide data to/from from objects (which effectively become the view objects) and the controller handles conversion to/from the form to the variables. I have even specd out a set of special classes which function as dynamic value objects for EJB and can be used as variables giving
2.0 Proposal example config files
I didnt include any example configuration files in my previous post and I thought they might help. These are from the working prototype. I also didnt mention the error handling which Ive added recently. The error handling is very powerful and allows the developer to use an "action" made up of re-usable steps to handle errors. The error handlers can be declared at the global level or at the pageflow or even action level and can be "overridden" by handlers at lower scopes. I also forgot to mention that anything at a lower scope "overrides" things at a higher scope. So if an action is declared at the struts-config level it can be used anywhere in the app, however if you also declare an action with the same name at the pageflow level that one will be used in the declaring pageflow. Paul T Smith ?xml version=1.0 encoding=UTF-8? !-- Created by psmith on April 18, 2002, 9:57 AM -- pageflow-application !-- configuration parameters -- configuration set-property id=request-processor property= value=/ !-- set the steps used by the app initialization flow -- request-processor-init-app step type=org.apache.struts.pageflow.engine.InitializeApplication/ step type=org.apache.struts.pageflow.engine.ExecuteApplication/ /request-processor-init-app !-- set the steps used by the process request flow -- request-processor-process-request step type=org.apache.struts.pageflow.engine.ProcessForm/ step type=org.apache.struts.pageflow.engine.ProcessValidation/ step type=org.apache.struts.pageflow.engine.ProcessAction/ /request-processor-process-request /configuration !-- Declare variables which can be used across the app. Only session and application scopes are valid, variables default to session scope. -- variable-declarations variable name=test type=java.lang.String initialValue=testString scope=session/ !-- dynamic types for declared complex objects. Good for wizards and such. -- variable name=test2 type=org.apache.struts.utils.gdo.GDO object attribute name=test type=java.lang.String value=Hello/ object name=testObj attribute name=testLvl2 type=java.lang.Integer/ /object list name=testObj object attribute name=testLvl2 type=java.lang.Integer/ /object /list map name=testObj object name=testMapEntry attribute name=testLvl2 type=java.lang.Integer/ /object /map /object /variable variable name=testInt type=java.lang.Integer initialValue=2 scope=session/ variable name=name type=java.lang.String initialValue=Page3 scope=session/ /variable-declarations !-- Filters which will run for the entire application. -- filters filter type=test/filter /filters !-- Declare error handlers available for entire application. -- error-handlers !-- An error handler has a name which can be referred to in other parts of the app -- error-handler name=Application action !-- Steps to execute for this error handler -- steps step type=org.apache.struts.pageflow.core.SetDestinationStep !-- Input parameters to the step. -- parameters param name=destination path=$engine/error/applicationError/ /parameters /step step type=org.apache.struts.pageflow.core.LogStep parameters param name=msg path=$engine/error/applicationError/ param name=msgDetail path=$engine/error/getMessage()/ /parameters /step /steps /action /error-handler error-handler name=test2 default=true action steps step type=org.apache.struts.pageflow.core.SetDestinationStep parameters param name=destination value=ReturnToPage/ /parameters /step step type=org.apache.struts.pageflow.core.LogStep parameters param name=msg path=$engine/error/applicationError/ param name=msgDetail path=$engine/error/message()/ /parameters /step /steps /action /error-handler /error-handlers !-- Global action declarations. -- actions !-- Action defines a grouped set of functionality calable from a page. An action can be refered to by name. If it is available to all it is automatically available from every page -- action name=end availableToAll=true steps step type=org.apache.struts.pageflow.core.SetDestinationStep parameters
RE: Struts commit access
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 10:19 PM To: Jakarta Project Management Committee List Cc: [EMAIL PROTECTED] Subject: Re: Struts commit access Karma granted. Welcome aboard James! Craig Pulling a piece of paper from my Tuxedo jacket. I'd like to thank the members of the Academy, my agent, my hair stylist, my Feng Shui consultant... Ooops, wrong speech. Here we go... Maniacal cackleThe power is mine, mine I say! They laughed when I told them I could deploy Struts on a Timex Sinclair! I'll show them, the fools! Igor, bring me the 200GB JVM! Seriously, I hope I can offer more light than heat to the effort. Let's ship that sucker! James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15805] New: - Enhance ModuleException to allow getting chained Exceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15805.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15805
Enhance ModuleException to allow getting chained Exceptions
Summary: Enhance ModuleException to allow getting chained
Exceptions
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
It'd be nice if it was possible to use a ModuleException to get a list of
chained exceptions and display them to the user.
I don't know how this would work, but using JDK 1.4, it might look something
like that below. This doesn't compile, but hopefully you get the idea - or
maybe I can already do it with this?
public class GeneralException extends ModuleException {
//~ Constructors ===
/**
* Construct a new instance of this exception
*/
public GeneralException() {
super(errors.general);
}
/**
* Constructor for this exception that allows you to pass in an exception
* with possible causes.
*
* @param e
*/
public GeneralException(Exception e) {
super(errors.detail, getChainedExceptions(e));
}
protected String getChainedExceptions(Exception e) {
StringBuffer sb = new StringBuffer();
if (e.getCause() == null) {
sb.append(e.getMessage());
} else {
while (e.getCause() != null) {
sb.append(e.getMessage());
sb.append(\n);
e = (Exception) e.getCause();
}
}
return sb.toString();
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15805] - Enhance ModuleException to allow getting chained Exceptions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15805. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15805 Enhance ModuleException to allow getting chained Exceptions [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Priority|Other |Low -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
New PMD and Checkstyle tasks
I've added two new tasks to the main build.xml file to allow us to easily run PMD and Checkstyle on the entire src/share source tree. Even if you don't know what these tools are, read on. PMD --- PMD is a Java source code analyzer which can detect many, many different kinds of problems, including unused imports, unused variables, etc., and report them in different ways. To run the PMD task, you need to first download PMD from here: http://sourceforge.net/projects/pmd/ and set the pmd.jar property in your build.properties file with something like this: pmd.jar = /Java/pmd/lib/pmd-1.01.jar Then you can invoke the task like this: ant pmd This will create an HTML output file named pmdreport.html in the Struts root directory. The task is configured to report only unused imports, duplicate imports, and unused variables and methods, but we can expand the set of checks and/or use multiple targets for different sets of checks as we gain more experience with it. Checkstyle -- Checkstyle is a tool that checks source code against a defined set of coding conventions. The default is to check against the Sun coding conventions, and I've left the settings at the default for now. To run the Checkstyle task, you need to first download Checkstyle from here: http://sourceforge.net/projects/checkstyle/ and set the checkstyle.jar property in your build.properties file with something like this: checkstyle.jar = /Java/checkstyle-2.4/checkstyle-all-2.4.jar Then you can invoke the task like this: ant -logfile checkstyle.log checkstyle Right now, you *will* need to specify a log file, because Checkstyle is reporting 9,884 errors! Note that I am *not* advocating that we start a crusade to fix these before Struts 1.1 Final. In fact, I think that would be counterproductive at this point. Each of the tasks described above is conditional on the corresponding property being set in your build.properties file. If the property is not set, invoking the task simply does nothing. At some point, it might be nice to have these tasks generate XML and run the output through XSLT to generate customised HTML. However, if we move to Maven (which I'd really like to do as soon as both 1.1 Final and Maven are released), we may not need to worry about this. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jelly actions (was Re: Another bright idea, make indexed workwith JSTL forEach and friends)
On Sat, 4 Jan 2003, Craig R. McClanahan wrote: 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. I've spent some time playing with writing actions in Jelly, and I think this has a *lot* of potential. The main issue at the moment has to do with the lack of pluggable scopes in Jelly. I actually started to work on this a while ago, but got derailed and never got back to it. I hope to find some time to finish what I started after Struts 1.1 Final. -- Martin Cooper 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]
