svn commit: r394670 - in /struts/sandbox/trunk/mailreader-course: ./ action2/lab-1-0/ action2/lab-1-0/src/java/ action2/lab-1-0/src/webapp/pages/ action2/lab-1-1/ action2/lab-1-2/ action2/lab-1-3/ act

Author: husted Date: Mon Apr 17 07:06:06 2006 New Revision: 394670 URL: http://svn.apache.org/viewcvs?rev=394670view=rev Log: MailReader Course / Action2 * Various minor changes found during the course's first presentation Modified: struts/sandbox/trunk/mailreader-course/STATUS.txt

XWork and Struts Action 2.0

What's the plan for XWork? I would recommend against keeping it as a third party dependency and for copying the necessary code over into the Struts repository and refactoring it (clean up exception handling, remove statics, better integrate APIs, etc.). We could keep the Java packages separate (if

Re: XWork and Struts Action 2.0

-1 to moving it over. XWork is not just part of WebWork, it's used other places. You're more than welcome to help do the cleanup in XWork for a 2.0 release. - Posted via Jive Forums

Re: XWork and Struts Action 2.0

Whether XWork is moved to Apache or not, I 100% agree the docs and API should be in a single location. WebWork has been doing this for a while, and I think we should continue the practice. The relationship between Action 2 and XWork could be like Action 1 and Commons Validator - the user

Re: XWork and Struts Action 2.0

This doesn't concern XWork itself. The question is can Struts continue to depend on XWork externally and actually be cohesive? I want one comprehensive manual. I don't necesarily want the servlet API to be readily available, but when I need it, I'd prefer not to go through a ThreadLocal. Having

Re: XWork and Struts Action 2.0

Bob Lee wrote: Also, how do the tags relate to JSTL? Are we just going to ignore JSTL? Or are we going to use JSTL for JSP with some WebWork-specific extensions and the WebWork tags for other template engines? I personally prefer the latter option. Struts has always tried to work well with

Re: ww:radio

This is a great feature suggestion, so could you please open up a ticket on it so it doesn't get forgotten? At the moment, we are focused on getting out of the Incubator, but soon, we hope to address issues such as this. http://issues.apache.org/struts Don Ricardo Lecheta wrote: Hi, In

Re: XWork and Struts Action 2.0

That it is used in other places isn't necessarily a reason not to move it over. Webwork as a whole, for example, is being used in far more places than XWork alone, yet we have decided to move that over. What I would propose if we did move it over would be to keep the relationship between

svn commit: r394828 - /struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java

Author: gvanmatre Date: Mon Apr 17 20:19:46 2006 New Revision: 394828 URL: http://svn.apache.org/viewcvs?rev=394828view=rev Log: Fix for bug 39294 reported by Simon Matic Langford. I narrowed the scope from the general category of renderer's in command family to the Link and Button renderer

DO NOT REPLY [Bug 39294] - ValidatorCommandRenderer breaks MyFaces dummy form.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39294. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39121. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 38079] - range validators doesn't check dependecies

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38079. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.