DO NOT REPLY [Bug 20509] - ErrorsTag display blank if resource not found
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=20509. 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=20509 ErrorsTag display blank if resource not found [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-05 15:05 --- Use message-resources null=false/ in struts-config.xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17418] New: - taglib/html/ErrorsTag
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=17418. 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=17418 taglib/html/ErrorsTag Summary: taglib/html/ErrorsTag Product: Struts Version: 1.1 RC1 Platform: Other OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello I think I find out bug... not e feature. All tags (at least which I know) from struts are started and finished whithout any line ends or etc. ONLY html:error tag is executed in a such a way: error.header + EOL + error + EOL + error.footer + EOL Imagine I'm using javaScript and I want, that one variable will have value, which comes from html:error tage. var error = Mr. Peksys you'v got an error ; won't work. In my opinion EOL(to show them or not) must be configurable. From as far as I know xml - it wouldn't be so hard to one attribute for a such a thing. And after looking at your code - I think it won't be also to change it P.S. Writing here because I notice, that you will releace 1.1 version. I checked code on 1.1 candidat, but there was the same bug/feature. So I hope that with next releace I dont have to change ErrorsTag class : Kind regards, Darius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17419] New: - taglib/html/ErrorsTag
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=17419. 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=17419 taglib/html/ErrorsTag Summary: taglib/html/ErrorsTag Product: Struts Version: 1.1 RC1 Platform: Other OS/Version: Linux Status: NEW Severity: Minor Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello I think I find out bug... not e feature. All tags (at least which I know) from struts are started and finished whithout any line ends or etc. ONLY html:error tag is executed in a such a way: error.header + EOL + error + EOL + error.footer + EOL Imagine I'm using javaScript and I want, that one variable will have value, which comes from html:error tage. var error = Mr. Peksys you'v got an error ; won't work. In my opinion EOL(to show them or not) must be configurable. From as far as I know xml - it wouldn't be so hard to one attribute for a such a thing. And after looking at your code - I think it won't be also to change it P.S. Writing here because I notice, that you will releace 1.1 version. I checked code on 1.1 candidat, but there was the same bug/feature. So I hope that with next releace I dont have to change ErrorsTag class : Kind regards, Darius - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10007] - ErrorsTag renders error header and footer even if they are null
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=10007. 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=10007 ErrorsTag renders error header and footer even if they are null [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-17 01:22 --- This is already fixed in any current nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ErrorsTag
Bugzilla is the best way to submit bugs and enhancements. http://nagoya.apache.org/bugzilla/ Of course attaching code to the bug/enhancements always helps too. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ --- Mirko Maischberger [EMAIL PROTECTED] wrote: I think i've acted in an unusual way. I've seen than errors.prefix and errors.suffix has been added to the ErrorsTag and I think format would be useful too for a lot of people working in the real world :). How can I propose this enanchenment (and patch)? Should I use bugzilla? How? Thanks, Mirko Il mar, 2002-06-11 alle 19:46, Mirko Maischberger ha scritto: Hello, I'm an italian java developer, and i'm now happily using struts since february. I've made a modified version ot the ErrorsTag which is compatible with the standard struts version but allows to have an errors.separator between errors to better customize the output and a format attribute to switch between errors.header errors.separator errors.footer and errors.format.header errors.format.separator errors.format.footer so the developer can easily use different formatting in different pages. I've also made a new tag which i named ErrorPresent which is a logic tag that signals the presence of errors or of field-specific errors. Do you think it can be useful for the project? If the team is interested i can post the patch. Hope I'm on topic. -- 1024D/5B35D286 Mirko Maischberger -- 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] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ErrorsTag
Hello, I'm an italian java developer, and i'm now happily using struts since february. I've made a modified version ot the ErrorsTag which is compatible with the standard struts version but allows to have an errors.separator between errors to better customize the output and a format attribute to switch between errors.header errors.separator errors.footer and errors.format.header errors.format.separator errors.format.footer so you can easily use different formatting in different pages. If the team is interested i can post the patch. I've also made a new tag which i named ErrorPresent which is a logic tag that signals the presence of errors or of field-specific errors. Do you think it can be useful for the project? Hope I'm on topic. -- 1024D/5B35D286 Mirko Maischberger Gli allegati potrebbero non ricevere immediata attenzione. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ErrorsTag
Hello, I'm an italian java developer, and i'm now happily using struts since february. I've made a modified version ot the ErrorsTag which is compatible with the standard struts version but allows to have an errors.separator between errors to better customize the output and a format attribute to switch between errors.header errors.separator errors.footer and errors.format.header errors.format.separator errors.format.footer so the developer can easily use different formatting in different pages. I've also made a new tag which i named ErrorPresent which is a logic tag that signals the presence of errors or of field-specific errors. Do you think it can be useful for the project? If the team is interested i can post the patch. Hope I'm on topic. -- 1024D/5B35D286 Mirko Maischberger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ErrorsTag
Hi there,
I am not sure if this is a bug or not, but I was
playing around with generating my own errors and found
that ErrorsTag.doStartTag() worked alot better for me
when I changed the last line in the code below (which
occurs twice in the method)
// Render header iff this is a global tag or
there is an error for this property
boolean propertyMsgPresent = reports.hasNext();
if ((message != null)(property == null) ||
propertyMsgPresent) {
to:
// Render header iff this is a global tag or
there is an error for this property
boolean propertyMsgPresent = reports.hasNext();
if ((message != null)(property == null) ||
propertyMsgPresent(property != null)) {
I also think it conforms more to the orignal
intention. Without this change I got null printed
out either side of my error text which I am setting
dynamically in my Action.
Hope this all makes sense. Like the product, the only
criticism is the html tags take some mind bending to
get used to (specifically the 'property' property and
how it relates to the Form and any attached beans). A
nice explanation in JavaWorld might be good though ...
Thanks v. much,
(do you have a mailing list?)
Adrian
http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug in Latest ErrorsTag
Perhaps I did something wrong in my use of the html:errors tag with a
specific property, but I believe I've discovered a bug. The problem arises
when I place code like this in a jsp:
html:errors property=searchCriteria/
I have an ActionError in scope with a name of 'searchCriteria' when this
code is executed. The error message that I specified shows up just fine,
but it is flanked by two nulls. I determined the problem to be the
non-existence of the errors.header and errors.footer properties. If I
defined these two properties, then instead of seeing this:
null X null
I would see
foo X bar
However, I don't want the header/footer in this instance. What is happening
is that the header and footer are being attached to the legitimate error
message, even when they are null. Here's the code from ErrorsTag.java:
if ((message != null)(property == null) ||
propertyMsgPresent) {
results.append(message);
results.append(\r\n);
}
The problem is that if propertyMsgPresent is true, the message var will be
appended even if it is null. (There is a duplicate of this code for the
footer.) I changed it to look like this:
if ((message != null)(property == null) ||
(propertyMsgPresent message != null)) {
results.append(message);
results.append(\r\n);
}
Which checks for the existence of message before appending it. Here's a
unified diff if anyone wants it.
Index: ErrorsTag.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v
retrieving revision 1.11
diff -u -r1.11 ErrorsTag.java
--- ErrorsTag.java 2001/07/16 00:44:54 1.11
+++ ErrorsTag.java 2001/09/10 19:01:49
@@ -244,7 +244,8 @@
reports = errors.get(property);
// Render header iff this is a global tag or there is an error for
this property
boolean propertyMsgPresent = reports.hasNext();
- if ((message != null)(property == null) || propertyMsgPresent) {
+ if ((message != null)(property == null) ||
+ (propertyMsgPresent message != null)) {
results.append(message);
results.append(\r\n);
}
@@ -264,7 +265,8 @@
message = RequestUtils.message(pageContext, bundle,
locale, errors.footer);
-if ((message != null)(property == null) || propertyMsgPresent) {
+if ((message != null)(property == null) ||
+ (propertyMsgPresent message != null)) {
results.append(message);
results.append(\r\n);
}
Joey
-- Sun Certified Java2 Programmer
-- My Pocket Smalltalk Stuff: www.joeygibson.com/st
--
-- We thought about killin' him, but we kinda
-- hated to go that far - Briscoe Darling
RE: ErrorsTag (was /contrib)
Since you are making changes in this area how about also extending the ActionError class so that it can hold an exception if one has been thrown? What I want to do when a serious problem occurs is to divert to an error page, display a friendly error message and write details of the problem as an html comment. I can do this at the moment by storing the Exception in the request but it would be more convenient if it was part of the ActionError, particularly if there is more than one. -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 12 July 2001 06:33 To: [EMAIL PROTECTED] Subject: Re: ErrorsTag (was /contrib) I checked in the changes I've made. There is an html:messages tag that iterates through the errors and is basically the same as the tag I had in the validator class except for the changes that were discussed. I've made an ActionMessages class and ActionMessage class. ActionErrors now extends ActionMessages and ActionError extends ActionMessage, but should work the exact same (basically the code from the errors classes is just in the parent). My thinking was that an error is basically a more a specific type of message. I haven't added the messagesExist tag yet because I'm not sure where it belongs. All the logic tags are very generic. Maybe it belongs in a taglib/validator package. If you read this Craig, maybe you could comment. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
I checked in the changes I've made. There is an html:messages tag that iterates through the errors and is basically the same as the tag I had in the validator class except for the changes that were discussed. I've made an ActionMessages class and ActionMessage class. ActionErrors now extends ActionMessages and ActionError extends ActionMessage, but should work the exact same (basically the code from the errors classes is just in the parent). My thinking was that an error is basically a more a specific type of message. I haven't added the messagesExist tag yet because I'm not sure where it belongs. All the logic tags are very generic. Maybe it belongs in a taglib/validator package. If you read this Craig, maybe you could comment. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
--- Ted Husted [EMAIL PROTECTED] wrote: Craig R. McClanahan wrote: Following this philosophy, we'd create a new tag (perhaps html:messages?) for the new functionality, and deprecate html:errors. In addition, we'd need to change the 1.1 implementation of html:errors so that it did something sensible, even in the face of a new and improved error messages object. The Validator package actually includes a general messages tag, which isn't much different from its errors tag. So maybe we should just add that one, and have it start by using the default ERRORS key. I believe people could then also use it for other messages just by specifying a different id property, and a different header or footer, if desired. I think all we would have to do is add an optional property property to messages and messagesExist. This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. Where would the messagesExist tag go? David http://home.earthlink.net/~dwinterfeldt/jsptags.html -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
This sounds good. I adding 'messages=true'. That makes it easier to use than have to put in a long key each time. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
