[OT] List problem - Long delays before some posts hit the mailing lists
Is anyone else experiencing strange delays with some messages? This message took neary two days to hit the list, but most others are pretty immediate. I've had the same thing happen several times on the user list. They seem to get there in the end, but must take a tour of the Internet before arriving. Steve -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: August 29, 2003 8:27 PM To: Struts Developers List Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag) -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: August 29, 2003 6:08 PM Each of us can only offer support from our own experience. If a person is not using the html taglib, then they might not know the html taglib solution. But if they are using JSTL, they might know a JSTL solution. Agreed, but I don't think we're *that* rusty on the Struts tags yet that we wouldn't be able to offer useful advice :-). There's no limit on the number of responses we can post to a question. If someone else knows the html taglib solution, then they can post that solution too. Yes, I had a very ... ummm ... interesting off-list discussion recently where I was trying to explain that to someone. I guess it's as much about perception as anything. I don't want to give the impression that the Struts tags are somehow unsupported or that JSTL is the *only* way to work. Also, in many people's eyes Struts 1.1 was only just released so any perceived change in the level support might be viewed negatively. I'm very happy for JSTL to be the recommendation, provided the commitment to the Struts tags until the end of their lifetime is clear and I feel sure it will be. ... -Ted. (Hey, maybe I should start answering the html taglib questions with the Velocity Tools solution!) That would certainly help dispel the Struts only works with JSPs myth. But I believe the standard answer to questions is, No! is crap. You want to use Perl :-) Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Short terms plans
As I opened my big mouth on this topic, I'll also keep a special eye out for any new bugs or patches that come in. Tiles Nested tags seem to be popular areas for issues to occur though, and I'm not particularly familiar with those. Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 31, 2003 3:02 PM To: Struts Developers List Subject: Re: Short terms plans On Sun, 31 Aug 2003, Ted Husted wrote: Date: Sun, 31 Aug 2003 15:31:22 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Short terms plans Craig R. McClanahan wrote: Sorry for the late response on this ... it seems like weekends are the only time I get to play with open source code any more :-(. I hear that, brother! =:0) The catch-as-catch-can thing isn't working for me anymore either, so I think I'll take my own advice http://jakarta.apache.org/struts/faqs/helping.html#corp and block out a regular time for open source development and call it part of the work week. I really want to Bugzilla sorted-out and fill in some of the remaining gaps in the documentation. Since we have a wiki now, I thought it might be helpful to setup a short term plans page. I took the liberty (surprise!) of adding some notes people have made on the list or in Bugzilla recently. http://nagoya.apache.org/wiki/apachewiki.cgi?action=editid=Struts ShortTermPlans I just added final cleanups to commons-resources to my list. Also, I setup a Job Jar page on the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar I'd like to add this item as well: * bA maintainer for the conventional Struts taglibs package is needed./b If you are motivated, self-starting developer who is actively using these tags, groks the Apache Way, and can spare the time, please take a look at the outstanding reports for the taglibs components, and start submitting patches for our consideration. +1. Lots of people rely on these tags, and will for a long time. But thought I should see if we have consensus on this first. At one time, we were not pursuing the conventional tags because we did not want to steer people away from JSTL. But now that we have an actively-supported JSTL tag library, it may be time to fish around for someone to actively maintain this package on behalf of the segment of our Community who need, or choose, to use these tags. Usually, I would suggest we let nature take its course and see if a taglib developer appears spontaneously. But, I think we may have given the community the impression that we are antagonistic towards these tags, and it may be prudent to take affirmative action to correct that impression. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/actions LookupDispatchAction.java
husted 2003/08/31 16:53:36
Modified:src/share/org/apache/struts/actions
LookupDispatchAction.java
Log:
Extend getLookupNameMethod from getMethod so that class is easier to extend, per
#22847.
Revision ChangesPath
1.15 +45 -24
jakarta-struts/src/share/org/apache/struts/actions/LookupDispatchAction.java
Index: LookupDispatchAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/LookupDispatchAction.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- LookupDispatchAction.java 13 Aug 2003 05:29:27 - 1.14
+++ LookupDispatchAction.java 31 Aug 2003 23:53:36 - 1.15
@@ -252,30 +252,19 @@
protected abstract Map getKeyMethodMap();
/**
- * Returns the method name, given a parameter's value.
+ * Lookup the method name corresponding to the client request's locale.
*
- * @param mapping The ActionMapping used to select this instance
- * @param form The optional ActionForm bean for this request (if any)
* @param request The HTTP request we are processing
- * @param response The HTTP response we are creating
- * @param parameter The codeActionMapping/code parameter's name
+ * @param keyName The parameter name to use as the properties key
+ * @param mapping The ActionMapping used to select this instance
*
- * @return The method's name.
- * @since Struts 1.2.1
- */
-protected String getMethodName(ActionMapping mapping,
- ActionForm form,
- HttpServletRequest request,
- HttpServletResponse response,
- String parameter)
-throws Exception {
-
-// Identify the method name to be dispatched to.
-// dispatchMethod() will call unspecified() if name is null
-String keyName = request.getParameter(parameter);
-if (StringUtils.isEmpty(keyName)) {
-return null;
-}
+ * @return The method's localized name.
+ * @throws ServletException if keyName cannot be resolved
+ * @since Struts 1.2.0
+ */ protected String getLookupMapName(HttpServletRequest request,
+ String keyName,
+ ActionMapping mapping)
+throws ServletException {
// Based on this request's Locale get the lookupMap
Map lookupMap = null;
@@ -308,5 +297,37 @@
return methodName;
}
+
+/**
+ * Returns the method name, given a parameter's value.
+ *
+ * @param mapping The ActionMapping used to select this instance
+ * @param form The optional ActionForm bean for this request (if any)
+ * @param request The HTTP request we are processing
+ * @param response The HTTP response we are creating
+ * @param parameter The codeActionMapping/code parameter's name
+ *
+ * @return The method's name.
+ * @since Struts 1.2.0
+ */
+protected String getMethodName(ActionMapping mapping,
+ ActionForm form,
+ HttpServletRequest request,
+ HttpServletResponse response,
+ String parameter)
+throws Exception {
+
+// Identify the method name to be dispatched to.
+// dispatchMethod() will call unspecified() if name is null
+String keyName = request.getParameter(parameter);
+if (StringUtils.isEmpty(keyName)) {
+return null;
+}
+
+String methodName = getLookupMapName(request, keyName, mapping);
+
+return methodName;
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/actions DispatchAction.java LookupDispatchAction.java MappingDispatchAction.java
husted 2003/08/31 16:58:08
Modified:src/share/org/apache/struts/actions DispatchAction.java
LookupDispatchAction.java
MappingDispatchAction.java
Log:
Javadoc changes only.
Revision ChangesPath
1.20 +6 -6
jakarta-struts/src/share/org/apache/struts/actions/DispatchAction.java
Index: DispatchAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/DispatchAction.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- DispatchAction.java 13 Aug 2003 17:19:58 - 1.19
+++ DispatchAction.java 31 Aug 2003 23:58:08 - 1.20
@@ -261,7 +261,7 @@
* Method which is dispatched to when the request is a cancel button submit.
* Subclasses of codeDispatchAction/code should override this method if
* they wish to provide default behavior different than returning null.
- * @since Struts 1.2.1
+ * @since Struts 1.2.0
*/
protected ActionForward cancelled(ActionMapping mapping,
ActionForm form,
@@ -372,7 +372,7 @@
* @param parameter The codeActionMapping/code parameter's name
*
* @return The method's name.
- * @since Struts 1.2.1
+ * @since Struts 1.2.0
*/
protected String getMethodName(ActionMapping mapping,
ActionForm form,
1.16 +4 -3
jakarta-struts/src/share/org/apache/struts/actions/LookupDispatchAction.java
Index: LookupDispatchAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/LookupDispatchAction.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- LookupDispatchAction.java 31 Aug 2003 23:53:36 - 1.15
+++ LookupDispatchAction.java 31 Aug 2003 23:58:08 - 1.16
@@ -154,6 +154,7 @@
* @author David Graham
* @author Leonardo Quijano
* @author Rob Leland
+ * @author Ted Husted
*/
public abstract class LookupDispatchAction extends DispatchAction {
1.5 +5 -5
jakarta-struts/src/share/org/apache/struts/actions/MappingDispatchAction.java
Index: MappingDispatchAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/MappingDispatchAction.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- MappingDispatchAction.java13 Aug 2003 17:19:58 - 1.4
+++ MappingDispatchAction.java31 Aug 2003 23:58:08 - 1.5
@@ -262,7 +262,7 @@
* @param parameter The codeActionMapping/code parameter's name
*
* @return The method's name.
- * @since Struts 1.2.1
+ * @since Struts 1.2.0
*/
protected String getMethodName(
ActionMapping mapping,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] List problem - Long delays before some posts hit the mailinglists
On Sun, 31 Aug 2003, Steve Raeburn wrote: Date: Sun, 31 Aug 2003 16:07:25 -0700 From: Steve Raeburn [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [OT] List problem - Long delays before some posts hit the mailing lists Is anyone else experiencing strange delays with some messages? This message took neary two days to hit the list, but most others are pretty immediate. I've had the same thing happen several times on the user list. They seem to get there in the end, but must take a tour of the Internet before arriving. Thank SoBig.F for that. The messages from this virus (and the stupid/useless responses from virus checkers that don't seem to understand that the From address is forged) have significantly impacted the responsiveness of mail servers all over the Internet, because they are busy handling all the useless traffic. Fortunately, it's supposed to expire on 9/10/03 ... Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8688] - Improved Javascript for Link Tag
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=8688. 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=8688 Improved Javascript for Link Tag [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-08-31 19:11 --- Since I wrote this cool technologies like jstl have come out. I believe adding this would be pointless. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16401] - ValidatorLookupDispatchAction
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=16401. 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=16401 ValidatorLookupDispatchAction [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Additional Comments From [EMAIL PROTECTED] 2003-08-31 19:20 --- Is anyone interested in this? I've since stopped using it and created a ActionValidator utility class that allows me to call the Validator from within my action classes by passing it a key. My new approach is not dependent on any Action Mapping Naming. I don't ever validate on the Form level because it disjoints the validation process. Anyways, please review this enhancement's history. If after reviewing this the ValidatorLookupDispatchAction is of interest to anyone then, please, let me know. If not I would like to close it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] List problem - Long delays before some posts hit the mailing lists
I could understand it if all list traffic was suffering delays, but it just seems to single out the occasional message while others get through in seconds. Oh well, one of the mysteries of the Internet. Just don't be too surprised if the odd message seems to be bizarrely out of touch with thread. More than usual anyway :-) Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 31, 2003 6:10 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: [OT] List problem - Long delays before some posts hit the mailing lists On Sun, 31 Aug 2003, Steve Raeburn wrote: Date: Sun, 31 Aug 2003 16:07:25 -0700 From: Steve Raeburn [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [OT] List problem - Long delays before some posts hit the mailing lists Is anyone else experiencing strange delays with some messages? This message took neary two days to hit the list, but most others are pretty immediate. I've had the same thing happen several times on the user list. They seem to get there in the end, but must take a tour of the Internet before arriving. Thank SoBig.F for that. The messages from this virus (and the stupid/useless responses from virus checkers that don't seem to understand that the From address is forged) have significantly impacted the responsiveness of mail servers all over the Internet, because they are busy handling all the useless traffic. Fortunately, it's supposed to expire on 9/10/03 ... Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
relative action paths
Hello, I am a new developer who is hoping someone here on this list can help me figure out this problem we are having: I need to be able to use relative paths so as to keep my URL (which varies quite a bit across our app) so instead of this: html:form action=/contactByEmail focus=name i want to be able to do this: html:form action=contactByEmail focus=name I found what looks to be a solution to this in the issues.apache.org/bugzilla site, #17449 but I'm not too sure how to integrate that patch/changes into my application. If anyone can offer some help or suggestions, it would be much appreciated! Thanks, Devin
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
Perhaps this belongs on the user list, but I think it is relevant for
the discussion at hand. You all seem to regard all of the Struts taglibs
as one item, for which JSTL is an alternative. While this is certainly
true for the logic: and bean: tags, I have not seen a replacement for
the
html: form tags (that is, html:form and all the controls) in JSTL.
The user guide
(http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
s)
suggests we replace
input type=text name=username
value=%= loginBean.getUsername() /
with
html:text property=username/
Does the use JSTL camp prefer this,
input type=text name=username
value=c:out value=${loginBean.username}/
or am I missing some basic JSTL?
Shai.
PS: There is a documentation error there; the original JSP should be
input type=text name=username
value=%= loginBean.getUsername() %/
--^
Shai.
---
Confidentiality Notice: This email transmission may contain confidential or legally
privileged information that is intended only for the individual or entity named in the
e-mail address. If you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the contents of this e-mail is
strictly prohibited. If you have received this e-mail transmission in error, please
reply to the sender, so that arrangements can be made for proper delivery, and then
please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
You are right, JSTL doesn't completely remove the need for Struts specific
tags.
I think for the purposes of this discussion, the next generation would be
JSTL plus the struts-el taglib and when we talk about the Struts tags, we're
really talking about the traditional, non-el tags.
So keep using the html:form and other Struts tag and consider migrating to
the EL versions if you are using JSTL.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: September 1, 2003 1:17 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
- Enhancement of the html:link tag)
Perhaps this belongs on the user list, but I think it is relevant for
the discussion at hand. You all seem to regard all of the Struts taglibs
as one item, for which JSTL is an alternative. While this is certainly
true for the logic: and bean: tags, I have not seen a replacement for
the
html: form tags (that is, html:form and all the controls) in JSTL.
The user guide
(http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
s)
suggests we replace
input type=text name=username
value=%= loginBean.getUsername() /
with
html:text property=username/
Does the use JSTL camp prefer this,
input type=text name=username
value=c:out value=${loginBean.username}/
or am I missing some basic JSTL?
Shai.
PS: There is a documentation error there; the original JSP should be
input type=text name=username
value=%= loginBean.getUsername() %/
--^
Shai.
---
Confidentiality Notice: This email transmission may contain
confidential or legally privileged information that is intended
only for the individual or entity named in the e-mail address. If
you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the
contents of this e-mail is strictly prohibited. If you have
received this e-mail transmission in error, please reply to the
sender, so that arrangements can be made for proper delivery, and
then please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/faqs struts-el.xml project.xml index.xml
husted 2003/09/01 06:01:05 Modified:doc/faqs project.xml index.xml Added: doc/faqs struts-el.xml Log: Port Struts EL readme into documentation. Revision ChangesPath 1.10 +4 -0 jakarta-struts/doc/faqs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/project.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- project.xml 29 Dec 2002 11:44:48 - 1.9 +++ project.xml 1 Sep 2003 13:01:05 - 1.10 @@ -35,6 +35,10 @@ item href=ssl.html name=SSL/ + +item +href=struts-el.html +name=Struts-EL (JSTL)/ /menu menu name=IDE Guides 1.13 +4 -0 jakarta-struts/doc/faqs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/index.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- index.xml 26 Jul 2003 03:56:25 - 1.12 +++ index.xml 1 Sep 2003 13:01:05 - 1.13 @@ -57,6 +57,10 @@ a href=ssl.htmlUsing the SSL protocol/a /li +li +a href=struts-el.htmlStruts EL Extension/a +/li + /ul /section 1.1 jakarta-struts/doc/faqs/struts-el.xml Index: struts-el.xml === ?xml version=1.0? document url=./struts-el.xml properties authorDavid Karr/author titleStruts EL Extension - Apache Struts/title /properties body chapter href=faq name=Struts EL Extension section href=Introduction name=Introduction p This subproject is an extension of the Struts tag library. Each JSP custom tag in this library is a subclass of an associated tag in the Struts tag library. One difference is that this tag library does not use rtexprvalues, it uses the expression evaluation engine in the Jakarta Taglibs implementation of the JSP Standard Tag Library (version 1.0) to evaluate attribute values. /p p In addition, some of the Struts tags were not ported to this library, as it was determined that their functionality was entirely supplied by the JSTL. These particular Struts tags, and the reason for their non-porting will be described in the documentation for this library. /p p In order to fully understand the correct utilization of this library, you must understand the use and operation of the Struts tag library, and the use and operation of the JavaServer Pages Standard Tag Library (hereafter called the JSTL), along with the expression language (sometimes called the EL) used for evaluating attribute values. /p /section section href=TagMapping name=Tag Mapping p In implementing the Struts-EL library, every Struts tag that provides a feature that is not covered by the JSTL (1.0) library is mapped into the Struts-EL library. This section reviews which Struts tags are NOT implemented in the Struts-EL library, and which JSTL tags provide that feature. /p p Many of the non-porting decisions were based on the fact that the JSTL expression language itself provides the same functionality. In those cases, in addition to a possible JSTL tag name, the symbol EL will be listed. /p p strong Bean Tag Library Tags NOT Implemented in Struts-EL/strong /p table border=1 trthStruts Tag/ththJSTL Tag/th/tr trtdcookie/tdtdc:set, EL/td/tr trtddefine/tdtdc:set, EL/td/tr trtdheader/tdtdc:set, EL/td/tr trtdinclude/tdtdc:import/td/tr trtdparameter/tdtdc:set, EL/td/tr trtdwrite/tdtd c:out/td/tr /table p strongBean Tag Library Tags NOT Implemented in Struts-EL/strong /p table border=1 trthStruts Tag/ththJSTL Tag/th/tr trtdempty/tdtdc:if, c:when, EL/td/tr trtdequal/tdtdc:if, c:when, EL/td/tr trtdgreaterEqual/tdtdc:if, c:when, EL/td/tr trtdgreaterThan/tdtdc:if, c:when, EL/td/tr trtdlessEqual/tdtdc:if, c:when, EL/td/tr trtdlessThan/tdtdc:if, c:when, EL/td/tr trtdnotEmpty/tdtdc:if, c:when, EL/td/tr trtdnotEqual/tdtdc:if, c:when, EL/td/tr /table p (Note that the iterate tag was originally ported, even with the presence of the c:forEach tag, as the indexed tag functionality was not supported when using c:forEach instead of logic:iterate. This has since been rectified, such that the indexed tag functionality checks for being contained in a
Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
Speaking of EL, I noticed we don't have EL versions of the Tiles tags. I
would be happy to provide the implementations, but I know it will be
tedious so I only want to proceed if there's a reasonably good chance
they will be added to the Struts distribution. Thoughts anyone?
In a private conversation Steve Raeburn indicated he would be interested
in these tags. Steve also pointed out we are missing the Nested tags,
but since I've never used those before I leave that tedious task to
someone else ;)
Matt
Steve Raeburn wrote:
You are right, JSTL doesn't completely remove the need for Struts specific
tags.
I think for the purposes of this discussion, the next generation would be
JSTL plus the struts-el taglib and when we talk about the Struts tags, we're
really talking about the traditional, non-el tags.
So keep using the html:form and other Struts tag and consider migrating to
the EL versions if you are using JSTL.
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: September 1, 2003 1:17 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465]
- Enhancement of the html:link tag)
Perhaps this belongs on the user list, but I think it is relevant for
the discussion at hand. You all seem to regard all of the Struts taglibs
as one item, for which JSTL is an alternative. While this is certainly
true for the logic: and bean: tags, I have not seen a replacement for
the
html: form tags (that is, html:form and all the controls) in JSTL.
The user guide
(http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
s)
suggests we replace
input type=text name=username
value=%= loginBean.getUsername() /
with
html:text property=username/
Does the use JSTL camp prefer this,
input type=text name=username
value=c:out value=${loginBean.username}/
or am I missing some basic JSTL?
Shai.
PS: There is a documentation error there; the original JSP should be
input type=text name=username
value=%= loginBean.getUsername() %/
--^
Shai.
---
Confidentiality Notice: This email transmission may contain
confidential or legally privileged information that is intended
only for the individual or entity named in the e-mail address. If
you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the
contents of this e-mail is strictly prohibited. If you have
received this e-mail transmission in error, please reply to the
sender, so that arrangements can be made for proper delivery, and
then please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19625] - DynaActionForm with LazyList support and WrapDynaActionForm capablity
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=19625. 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=19625 DynaActionForm with LazyList support and WrapDynaActionForm capablity --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 18:05 --- Created an attachment (id=8024) Added FactoryUtils support in anticipation of Collections 3.0. I have generated a full patch of all the changes associated with this enhancement. Please use this patch as current for all changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22864] - LookupDispatchAction and DispatchAction getMethodName enhancement
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=22864. 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=22864 LookupDispatchAction and DispatchAction getMethodName enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:02 --- Created an attachment (id=8025) DispatchAction patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22864] New: - LookupDispatchAction and DispatchAction getMethodName enhancement
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=22864. 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=22864 LookupDispatchAction and DispatchAction getMethodName enhancement Summary: LookupDispatchAction and DispatchAction getMethodName enhancement Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Rather than returning null with the getMethodName when a value is not specified it is preferable that it actually return a value. I am attaching a patch that causes the getMethodName to return unspecified rather than null. I wrote some custom Actions that were very similar to the LDA and DA because the LDA did not provide the neccessary hooks to get at certain information. Being that the getMethodName is protected it is available for use in extended actions. I just don't like the idea of having to do a null check in my code in order to get the string unspecified when it could be done in the LDA and DA action themselves. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22864] - LookupDispatchAction and DispatchAction getMethodName enhancement
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=22864. 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=22864 LookupDispatchAction and DispatchAction getMethodName enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:03 --- Created an attachment (id=8026) LookupDispatchAction patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22864] - LookupDispatchAction and DispatchAction getMethodName enhancement
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=22864. 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=22864 LookupDispatchAction and DispatchAction getMethodName enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 19:05 --- Created an attachment (id=8027) This is the real DispatchAction patch. The other was the wrong patch... Sorry Wish i could delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16401] - ValidatorLookupDispatchAction
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=16401. 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=16401 ValidatorLookupDispatchAction [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEW --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 12:06 --- How about attaching your ActionValidator utilitity for consideration instead, Brandon? A lot of people feel the same way about disjointed validations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16401] - ValidatorLookupDispatchAction
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=16401. 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=16401 ValidatorLookupDispatchAction --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 15:27 --- Created an attachment (id=8023) This is the ActionValidatorUtil that is used to call validator from within an Action class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16401] - ActionValidatorUtil
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=16401. 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=16401 ActionValidatorUtil [EMAIL PROTECTED] changed: What|Removed |Added URL|http://www.phase.ws/struts/ | Summary|ValidatorLookupDispatchActio|ActionValidatorUtil |n | --- Additional Comments From [EMAIL PROTECTED] 2003-09-01 15:34 --- This utility allows for you to validate forms, beans, or any other javabean compliant class from within the Action. You simply pass it a validation key and the bean you want to validate. It will create an ActionErrors object for you or you can pass in an already existing ActionErrors object. This provides a greater amount of reuse with validator configuration because it doesn't have to be on the form level. Therefore, you can create more fine-grained validators for your beans. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
Sgarlata == Sgarlata Matt [EMAIL PROTECTED] writes: Sgarlata Speaking of EL, I noticed we don't have EL versions of the Tiles tags. I would Sgarlata be happy to provide the implementations, but I know it will be tedious so I Sgarlata only want to proceed if there's a reasonably good chance they will be added to Sgarlata the Struts distribution. Thoughts anyone? Sgarlata In a private conversation Steve Raeburn indicated he would be interested in Sgarlata these tags. Steve also pointed out we are missing the Nested tags, but since Sgarlata I've never used those before I leave that tedious task to someone else ;) I've been intending to produce at least a tiles-el library, and possibly a nested-el library, but I've been trying to watch for a significant level of interest for this. I very occasionally see a mention of a desire for tiles-el, and less so for nested-el. I haven't looked at those libraries for a while, so I'm not certain how much value there will be for this. If there's really significant interest in this, I could proceed with this, first doing tiles-el, and then nested-el. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Short terms plans
Ted or Anyone else for that matter. I've been looking through the source and have a few ideas of bits i'd like to add and such forth. I've been following the discussions on focusing struts development away from the tags. Although I've almost been won over by JSTL, I still think that lack the clarity of struts tags. I'd be glad to pitch in but I've been having trouble getting the information I want. I'll have to find a browser that will display the buglist rather than download it when i click on it too. kinda tricky to enter as a bug that one. Anyway I'd love to have a crack, but I may need some guidance to get me going. How much would i have to know about maven and gump? for one thing (well actually two). Cheers Mark On Sunday, August 31, 2003, at 08:31 PM, Ted Husted wrote: Craig R. McClanahan wrote: Sorry for the late response on this ... it seems like weekends are the only time I get to play with open source code any more :-(. I hear that, brother! =:0) The catch-as-catch-can thing isn't working for me anymore either, so I think I'll take my own advice http://jakarta.apache.org/struts/faqs/helping.html#corp and block out a regular time for open source development and call it part of the work week. I really want to Bugzilla sorted-out and fill in some of the remaining gaps in the documentation. Since we have a wiki now, I thought it might be helpful to setup a short term plans page. I took the liberty (surprise!) of adding some notes people have made on the list or in Bugzilla recently. http://nagoya.apache.org/wiki/ apachewiki.cgi?action=editid=StrutsShortTermPlans Also, I setup a Job Jar page on the Wiki http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsJobJar I'd like to add this item as well: * bA maintainer for the conventional Struts taglibs package is needed./b If you are motivated, self-starting developer who is actively using these tags, groks the Apache Way, and can spare the time, please take a look at the outstanding reports for the taglibs components, and start submitting patches for our consideration. But thought I should see if we have consensus on this first. At one time, we were not pursuing the conventional tags because we did not want to steer people away from JSTL. But now that we have an actively-supported JSTL tag library, it may be time to fish around for someone to actively maintain this package on behalf of the segment of our Community who need, or choose, to use these tags. Usually, I would suggest we let nature take its course and see if a taglib developer appears spontaneously. But, I think we may have given the community the impression that we are antagonistic towards these tags, and it may be prudent to take affirmative action to correct that impression. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
