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

[husted]

Author: husted
Date: Mon Apr 17 07:06:06 2006
New Revision: 394670

URL: http://svn.apache.org/viewcvs?rev=394670&view=rev
Log:
MailReader Course / Action2 
* Various minor changes found during the course's first presentation

Modified:
struts/sandbox/trunk/mailreader-course/STATUS.txt
struts/sandbox/trunk/mailreader-course/action2/lab-1-0/lab-1-0.iml

struts/sandbox/trunk/mailreader-course/action2/lab-1-0/src/java/resources.properties

struts/sandbox/trunk/mailreader-course/action2/lab-1-0/src/webapp/pages/Hello.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-1-1/lab-1-1.iml
struts/sandbox/trunk/mailreader-course/action2/lab-1-2/lab-1-2.iml
struts/sandbox/trunk/mailreader-course/action2/lab-1-3/lab-1-3.iml

struts/sandbox/trunk/mailreader-course/action2/lab-1-3/src/java/Register.java
struts/sandbox/trunk/mailreader-course/action2/lab-2-1/lab-2-1.iml

struts/sandbox/trunk/mailreader-course/action2/lab-2-1/src/java/Register.java
struts/sandbox/trunk/mailreader-course/action2/lab-2-2/lab-2-2.iml

struts/sandbox/trunk/mailreader-course/action2/lab-2-2/src/java/Register.java
struts/sandbox/trunk/mailreader-course/action2/lab-2-3/lab-2-3.iml
struts/sandbox/trunk/mailreader-course/action2/lab-2-3/src/java/Login.java

struts/sandbox/trunk/mailreader-course/action2/lab-2-3/src/java/MailReaderSupport.java

struts/sandbox/trunk/mailreader-course/action2/lab-2-3/src/java/Register.java

struts/sandbox/trunk/mailreader-course/action2/lab-2-3/src/webapp/pages/Register.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-3-1/lab-3-1.iml

struts/sandbox/trunk/mailreader-course/action2/lab-3-1/src/java/resources_ja.properties

struts/sandbox/trunk/mailreader-course/action2/lab-3-1/src/webapp/pages/Welcome.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-3-2/lab-3-2.iml

struts/sandbox/trunk/mailreader-course/action2/lab-3-2/src/java/Register.java
struts/sandbox/trunk/mailreader-course/action2/lab-3-2/src/java/xwork.xml

struts/sandbox/trunk/mailreader-course/action2/lab-3-2/src/webapp/pages/Register.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-3-3/lab-3-3.iml
struts/sandbox/trunk/mailreader-course/action2/lab-3-3/src/java/xwork.xml

struts/sandbox/trunk/mailreader-course/action2/lab-3-3/src/webapp/pages/Register.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-3-3/src/webapp/pages/Welcome.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-4-1/lab-4-1.iml
struts/sandbox/trunk/mailreader-course/action2/lab-4-1/src/java/xwork.xml

struts/sandbox/trunk/mailreader-course/action2/lab-4-1/src/webapp/pages/Register.jsp
struts/sandbox/trunk/mailreader-course/action2/lab-4-2/lab-4-2.iml
struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/java/xwork.xml

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/WEB-INF/web.xml

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Hello.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Login.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Menu.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Missing.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Register.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Subscribe.jsp

struts/sandbox/trunk/mailreader-course/action2/lab-4-2/src/webapp/pages/Welcome.jsp

Modified: struts/sandbox/trunk/mailreader-course/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/mailreader-course/STATUS.txt?rev=394670&r1=394669&r2=394670&view=diff
==
--- struts/sandbox/trunk/mailreader-course/STATUS.txt (original)
+++ struts/sandbox/trunk/mailreader-course/STATUS.txt Mon Apr 17 07:06:06 2006
@@ -26,8 +26,8 @@
 
 * Present and apply MVC application architecture
 * Build a working web application
-* Understand how to unit test web application
-* Explain key best practices
+* Understand how to unit test web applications
+* Explore key best practices
 * Use popular extensions to increase productivity
 
 AUDIENCE

Modified: struts/sandbox/trunk/mailreader-course/action2/lab-1-0/lab-1-0.iml
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/mailreader-course/action2/lab-1-0/lab-1-0.iml?rev=394670&r1=394669&r2=394670&view=diff
==
--- struts/sandbox/trunk/mailreader-course/action2/lab-1-0/lab-1-0.iml 
(original)
+++ struts/sandbox/trunk/mailreader-course/action2/lab-1-0/lab-1-0.iml Mon Apr 
17 07:06:06 2006
@@ -12,7 +12,6 @@
 
 
 
-
 
   
 
@@ -250,7 +249,11 @@
   jar://$MODULE_DIR$/../../lib/xwork-1.1.2.jar!/
 
 
-
+
+  
+  
+  
+
 

XWork and Struts Action 2.0

[Bob Lee]

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 we really think it's worth it), but there's
definitely no need for two separate projects. Looking in two places
for the documentation and API is a huge pain, not to mention confusing
for new users.

Bob

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XWork and Struts Action 2.0

[Matt Raible]

+1 to moving it over. I don't care about package naming, but agree the
Javadocs should be in the same location.

Matt

On 4/17/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> 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 we really think it's worth it), but there's
> definitely no need for two separate projects. Looking in two places
> for the documentation and API is a huge pain, not to mention confusing
> for new users.
>
> Bob
>
> -
> 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: XWork and Struts Action 2.0

[Jason Carreira]

-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
http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XWork and Struts Action 2.0

[Don Brown]

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 doesn't have to go to the Commons Validator site for docs; they are 
well-integrated.


Don

Bob Lee wrote:

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 we really think it's worth it), but there's
definitely no need for two separate projects. Looking in two places
for the documentation and API is a huge pain, not to mention confusing
for new users.

Bob

-
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: XWork and Struts Action 2.0

[Bob Lee]

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 two
completely separate projects where one project that generates two jars
would make more sense has always gotten on my nerves. I think it will
be even worse now that the two projects are at different sites.

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?

Are we going to continue using OGNL, or are we going to use JSP EL?

Bob

On 4/17/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
> -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
> http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716
>
>
> -
> 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: XWork and Struts Action 2.0

[Don Brown]

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 standards, and JSTL should be no 
exception.  I guess the question is whether the overlap tags will be deleted or just deprecated.  I'm fine with deleted.



Are we going to continue using OGNL, or are we going to use JSP EL?


This is a good, yet complicated question that has seen much discussion lately.  The bottom line is there are features in 
OGNL that we can't live without: type conversions, projection, and method calls to name a few.  If we can somehow either 
a) extend the JSP EL to support these features or b) implement OGNL behind the JSP EL API's, I see a future in closer 
collaboration.  From what I understand, both are possible, just waiting for someone to step up and do the work.


Good to see you on the list, and congrats on the marriage.  I admit I was a 
little jealous as to its location :)

Don



Bob

On 4/17/06, Jason Carreira <[EMAIL PROTECTED]> wrote:

-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
http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716


-
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]

Re: ww:radio

[Don Brown]

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 webwork the ww:radio tag evaluates a list using ognl... The ww:radio from 
webwork is amazing, but sometimes you don´t want put a getList() in your 
Action.

The html:radio from Struts is very easy to use, and you don´t need a 
collection to fill the radios..

Is it possible in SAF2 both of ww:radio from WW2 and html:radio from Struts 
exists?

thanks,
Ricardo
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26152&messageID=51516#51516


-
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: XWork and Struts Action 2.0

[Gabe]

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 XWork and Webwork the way it is now but under the Struts Action 
Framework 2 umbrella (call it for example Struts 2 core and Struts 2 web). 
Thus, those projects that currently use XWork would simply depend on Struts 2 
core rather than XWork. If we are able to move over the user base successfully, 
those XWork dependent projects would benefit as well from the increase of the 
user base that knows XWork, like it and want to extend its functionality. (A 
more solid Springwork might emerge for example). 

It would be easier to define documentation if they were both under a Struts 
umbrella as well. For example, A "webwork action" never really made sense, but 
a "struts action" since both would be divisions of struts would.

It's telling that the lion's share of code related issues we've discussed so 
far about Struts 2 on this list (Annotation driven actions, pluggability of 
expression language, use of "dev mode", etc., etc.) are really issues that 
should be brought to the XWork project and aren't really within the scope of 
what the Webwork project was. Thus,  if we don't move over XWork, an important 
task would be to redefine that relationship.

Now, the last time I wrote a message like this, i was told to get the XWork 
developers involved, so I think I will go do that now. ;-)

Gabe

- Original Message 
From: Jason Carreira <[EMAIL PROTECTED]>
To: dev@struts.apache.org
Sent: Monday, April 17, 2006 4:37:59 PM
Subject: 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
http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716


-
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]

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

[gvanmatre]

Author: gvanmatre
Date: Mon Apr 17 20:19:46 2006
New Revision: 394828

URL: http://svn.apache.org/viewcvs?rev=394828&view=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 type's that are specified in the JSF runtime and have know behavior.  


Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java?rev=394828&r1=394827&r2=394828&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ValidatorRenderKit.java
 Mon Apr 17 20:19:46 2006
@@ -35,6 +35,9 @@
  * The majority of the implementation is passed on the the original 
  * RenderKit but requests for renderers registered with the 
  * "javax.faces.Command" and "javax.faces.Input" families are decorated.
+ * Only renderers in the "javax.faces.Command" family of types 
+ * "javax.faces.Link" and "javax.faces.Button" are considered.  These are
+ * renderers from the vanilla JSF runtime that have predictable behavior.  
  * The wrapper adds special behavior for the 
  * [EMAIL PROTECTED] org.apache.shale.validator.CommonsValidator} validator and
  * [EMAIL PROTECTED] org.apache.shale.component.ValidatorScript} component.
@@ -44,6 +47,9 @@
 private static String COMMAND_FAMILY = "javax.faces.Command";
 private static String INPUT_FAMILY = "javax.faces.Input";
 
+private static String COMMAND_LINK_TYPE = "javax.faces.Link";
+private static String COMMAND_BUTTON_TYPE = "javax.faces.Button";
+
 
 /**
  * The original RenderKit.
@@ -65,14 +71,17 @@
 /**
  * If the component family is not "javax.faces.Command" or
  * "javax.faces.Input", the defaultRenderKit handles the 
- * request.  If the family is "javax.faces.Command", the default
- * renderer is decorated with [EMAIL PROTECTED] 
org.apache.shale.renderer.ValidatorCommandRenderer}.
+ * request.  If the family is "javax.faces.Command", and the renderer type
+ * is "javax.faces.Link" or "javax.faces.Button" the default
+ * renderer is decorated with [EMAIL PROTECTED] 
org.apache.shale.renderer.ValidatorCommandRenderer}. 
  * If the component family is "javax.faces.Input", the default 
  * renderer is decorated with [EMAIL PROTECTED] 
org.apache.shale.renderer.ValidatorInputRenderer}.
  */
 public Renderer getRenderer(String componentFamily, String rendererType) {
 Renderer target = defaultRenderKit.getRenderer(componentFamily, 
rendererType);
-if (componentFamily.equals(COMMAND_FAMILY)) {
+if (componentFamily.equals(COMMAND_FAMILY) && 
+(rendererType.equals(COMMAND_LINK_TYPE) || 
+ rendererType.equals(COMMAND_BUTTON_TYPE))) {
if (!(target instanceof ValidatorCommandRenderer)) {
target = new ValidatorCommandRenderer(target);
addRenderer(componentFamily, rendererType, target);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39294


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-18 03:23 ---
I narrowed the scope from the general category of renderer's in command family 
to the Link and Button renderer type's that are specified in the JSF runtime 
and have know behavior.  The fix should be in the shale 20060418 nightly build.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39121


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-18 03:25 ---
The current implementation is dependent on version 1.3 of commons validator. 
Some new conventions have been adopted for registering a validation rule in 
the validator's XML configuration file. In the action framework, validation 
was suited for declaring rules associated with a form. This worked well since 
generally a single action had the responsibility of handling all the posted 
form data at once.

However, JSF takes a component based approach. Each component has the 
responsibility of managing its posted data and rendering its state. In the 
component based world, it is easier to associated configuration values at that 
level versus what works best for struts action.

In an effort to reuse as much of commons validator and provide a method of 
registering new rules, a new convention was adopted for declaring validation 
rules. 


  

The rules declaration is the same but an added form is required to capture 
extra configuration information. The form is associated with the validation 
rule using a naming convention. The prefix of the form name 
is "org.apache.shale.validator." where "" is the validation rule name.

   
 
The form is followed by a field and the property attribute of the form has the 
same value as the rule name.

   

Within the field definition, arg's are used to define the parameters in order 
for message substitution and method argument value resolution.
There are two reserved name values for the arg node used to define messages 
and parameters.

   
   
   
   
 

The "message" name arguments defines the possible MessageFormat parameter 
substitution where the "position" corresponds to the substitution parameter.

errors.invalid={0} is invalid.

The "parameter" arguments define the variable names that hold values for the 
target validatior method identified by the validator rule name. The comma 
delimited class types in the "methodParms" value list correspond to the 
parameters by position.
  
  methodParams="java.lang.String,java.lang.String"
 
The var node is also used to explicitly define a JavaScript variable type. If 
not defined, the default is "string". The var-value is ignored because its 
captured by the shale commons validator instance.

   
   mask
  
  regexp



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38079


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-04-18 03:28 ---
This problem is fixed with bug 39121.  The fix will be in the 20060418 nightly 
shale build.  Thanks for the help. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]