DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

2006-03-30 Thread 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=39040





--- Additional Comments From [EMAIL PROTECTED]  2006-03-30 13:56 ---
As Hubert pointed out, there are already ways to do augment the initialization
process without getting involved in this specific listener.  That said, I would
probably do something to make the chain extensible/replaceable.

My intention, again, is to try to start down the path of integrating Struts 1.x
compatibility in SAF 2.x.  My idea (more of a gut feeling than a thoroughly
reasoned stance) is that integration is better than just dropping in
ActionServlet and making things go in parallel.  Also, when I've tried to do
things with the init process in ActionServlet before, it has often been awkward
to work in there, so I think this will just help clarify what goes on there.

If there are other positive side effects, like testing, that's great.

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



svn commit: r390119 - in /struts/site/trunk/xdocs: faqs.xml kickstart.fml products.fml

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 05:27:18 2006
New Revision: 390119

URL: http://svn.apache.org/viewcvs?rev=390119&view=rev
Log:
FAQs 
* Add "newbie" and "roots" FAQs

Added:
struts/site/trunk/xdocs/products.fml
Modified:
struts/site/trunk/xdocs/faqs.xml
struts/site/trunk/xdocs/kickstart.fml

Modified: struts/site/trunk/xdocs/faqs.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/faqs.xml?rev=390119&r1=390118&r2=390119&view=diff
==
--- struts/site/trunk/xdocs/faqs.xml (original)
+++ struts/site/trunk/xdocs/faqs.xml Thu Mar 30 05:27:18 2006
@@ -34,6 +34,10 @@
 
 
 
+Product Line FAQ
+
+
+
 How to Help FAQ
 
 

Modified: struts/site/trunk/xdocs/kickstart.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/kickstart.fml?rev=390119&r1=390118&r2=390119&view=diff
==
--- struts/site/trunk/xdocs/kickstart.fml (original)
+++ struts/site/trunk/xdocs/kickstart.fml Thu Mar 30 05:27:18 2006
@@ -19,7 +19,57 @@
 
 
 
-Project Details
+  
+I'm new to Apache Struts. How do I get started?
+
+
+
+A good starting point to learn more about Struts Action is the
+website where you found this FAQ.
+The best available release is
+http://struts.apache.org/announce.html#a20050322";>
+Struts 1.2.9.
+
+
+
+The Struts 1.2.9 release has its
+http://struts.apache.org/struts-doc-1.2.9/index.html";>
+own area of the website. The main website is devoted to the
+upcoming version, Struts Action 1.3. This version is at the
+"http://svn.apache.org/dist/struts/action-lib/";>test
+build" stage now, but it is still 100% backwardly compatible
+with Struts 1.2.9.
+
+
+
+Meanwhile, we are in the process of "joining forces" with another
+project,
+http://www.opensymphony.com/webwork/";>OpenSymphony
+WebWork.
+The WebWork codebase is being
+http://incubator.apache.org/projects/webwork2.html";>
+donated to Apache Struts
+and the WebWork developers have joined the Apache Struts team.
+Essentially, Struts Action 2.0 will be WebWork 2.3.
+
+
+
+To learn more about using Apache Struts, you can also visit
+http://www.StrutsCentral.net/";>Struts Central,
+which catalogs all the known resources about Apache Struts, 
whether it is
+http://struts.apache.org/struts-action/";>Action 1,
+http://wiki.apache.org/struts/StrutsTi";>Action 2,
+or our offering for JavaServer Faces,
+http://struts.apache.org/struts-shale/";>Struts Shale.
+To keep up on the latest news about "everything Struts",
+point your RSS reader at the
+http://www.PlanetStruts.org/";>Planet Struts news site.
+If you still have questions, you can search the
+User Mailing List archives,
+or post your own question to the list.
+(Plain old Google often works too!)
+
+
 
 
 Why is the project called Struts?
@@ -282,476 +332,10 @@
 
 
 
-
-
-Product Line
-
-
-Why are you offering both the Struts Shale and the 
Struts Action
-Framework? Don't they compete for new development?
-
-We do offer Apache Struts developers a choice, but, hey,
-choice is good. :)
-People who want to create and maintain the
-Struts Action
-Framework
-are welcome to do so.
-
-People who want to create and maintain the
-Struts Shale
-Framework
-are equally welcome.
-
-As a volunteer organization, we are not constrained by the
-economics of competition. All we need are volunteers who
-are ready, willing, and able to do the work. So long as we
-have volunteers, we have work for them to do.
-Right now, we have volunteers who want to leverage the new
-JavaServer Faces framework by using Struts Shale for new
-development. We also have volunteers who prefer to
-leverage their existing investment in Struts Action
-Framework. All are welcome.
-For more about volunteering, visit

svn commit: r390123 - /struts/site/trunk/xdocs/products.fml

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 05:30:36 2006
New Revision: 390123

URL: http://svn.apache.org/viewcvs?rev=390123&view=rev
Log:
Product FAQ 
* Typo.

Modified:
struts/site/trunk/xdocs/products.fml

Modified: struts/site/trunk/xdocs/products.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/products.fml?rev=390123&r1=390122&r2=390123&view=diff
==
--- struts/site/trunk/xdocs/products.fml (original)
+++ struts/site/trunk/xdocs/products.fml Thu Mar 30 05:30:36 2006
@@ -162,13 +162,13 @@
   Backward compatibility has almost become an obsession with us.
   Before making any API change, we deprecate the existing member,
   and make at least one milestone release before removing the 
member.
-  Each Struts Action milestone is drop-and-go compatibility with 
the last.
+  Each Struts Action milestone is drop-and-go compatibile with the 
last.
   Maintaining this degree of stability takes a lot of effort,
   but given the installed base, we feel it is worth the time and 
trouble.
 
 
   There have been several proposals for a new Struts Action 2 
codebase.
-  The first was
+  The first formal proposal was
   http://wiki.apache.org/struts/StrutsJericho";>Jericho,
   followed by
   http://wiki.apache.org/struts/StrutsShale";>Shale,



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



svn commit: r390125 - /struts/site/trunk/xdocs/products.fml

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 05:36:01 2006
New Revision: 390125

URL: http://svn.apache.org/viewcvs?rev=390125&view=rev
Log:
Product FAQ 
* Typo.

Modified:
struts/site/trunk/xdocs/products.fml

Modified: struts/site/trunk/xdocs/products.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/products.fml?rev=390125&r1=390124&r2=390125&view=diff
==
--- struts/site/trunk/xdocs/products.fml (original)
+++ struts/site/trunk/xdocs/products.fml Thu Mar 30 05:36:01 2006
@@ -161,8 +161,8 @@
   The Struts Action 1.x series is deeply into "backward 
compatibility" mode.
   Backward compatibility has almost become an obsession with us.
   Before making any API change, we deprecate the existing member,
-  and make at least one milestone release before removing the 
member.
-  Each Struts Action milestone is drop-and-go compatibile with the 
last.
+  and make at least one milestone release before removing the 
deprecated member.
+  Each Struts Action milestone is drop-and-go compatible with the 
last.
   Maintaining this degree of stability takes a lot of effort,
   but given the installed base, we feel it is worth the time and 
trouble.
 
@@ -335,7 +335,7 @@
 
 
 
-So many decisions! Shouldn't it be simplier?
+So many decisions! Shouldn't it be simpler?
 
 
 Yes, there seems to be nothing but choice when it comes to



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



svn commit: r390135 - in /struts/site/trunk/xdocs: index.xml kickstart.fml

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 05:55:32 2006
New Revision: 390135

URL: http://svn.apache.org/viewcvs?rev=390135&view=rev
Log:
kickstart FAQ
* Newbie - Condense opening paragraphs
Welcome 
* Typo. Update links. 

Modified:
struts/site/trunk/xdocs/index.xml
struts/site/trunk/xdocs/kickstart.fml

Modified: struts/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/index.xml?rev=390135&r1=390134&r2=390135&view=diff
==
--- struts/site/trunk/xdocs/index.xml (original)
+++ struts/site/trunk/xdocs/index.xml Thu Mar 30 05:55:32 2006
@@ -103,7 +103,7 @@
 
 
 
-If you are starting a new project want to use the latest
+If you are starting a new project and want to use the 
latest
 technology,
 don't worry, we are still blazing trails, same as ever.
 For projects using JavaServer Faces, we offer the Shale
@@ -116,8 +116,10 @@
 Is that all there is?
 Not by a long shot!
 Soon, we will also offer a new Action 2 framework, based on
-WebWork
-technology. Essentially, Struts Action 2.0 will be WebWork 
2.3.
+http://www.opensymphony.com/webwork/";>WebWork
+technology. Essentially, 
+Struts Action 2.0 
+will be WebWork 2.3.
 
 
 

Modified: struts/site/trunk/xdocs/kickstart.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/kickstart.fml?rev=390135&r1=390134&r2=390135&view=diff
==
--- struts/site/trunk/xdocs/kickstart.fml (original)
+++ struts/site/trunk/xdocs/kickstart.fml Thu Mar 30 05:55:32 2006
@@ -24,14 +24,9 @@
 
 
 
-A good starting point to learn more about Struts Action is the
-website where you found this FAQ.
-The best available release is
+The best available release of Apache Struts is
 http://struts.apache.org/announce.html#a20050322";>
 Struts 1.2.9.
-
-
-
 The Struts 1.2.9 release has its
 http://struts.apache.org/struts-doc-1.2.9/index.html";>
 own area of the website. The main website is devoted to the



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



DO NOT REPLY [Bug 39155] New: - Faces context not found

2006-03-30 Thread 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=39155

   Summary: Faces context not found
   Product: Struts
   Version: Unknown
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Faces
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi guys! I'm trying to run the Struts-Faces examples but, they only work when 
I run them under Tomcat. When I try to run them under Jboss-4.0.3 I always get 
the following error:

"Faces context not found. getResponseWriter will fail. Check if the 
FacesServlet has been initialized at all in your web.xml.
10:27:02,015 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
at javax.faces.webapp.UIComponentTag.setupResponseWriter
(UIComponentTag.java:615)"

Any ideas?
Thanks in advance!

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



Re: WebWork renaming strategy *revised*

2006-03-30 Thread Ian Roughley


Ted Husted wrote:


STATUS so far

- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:

+1 Don Brown, Martin Cooper (binding)
+1 Frank Zammetti  (non-binding)

- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:

 


+1 with the saf tag prefix


+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen (binding)
+0 Toby Jee, Hubert Rabago (binding)
+1 Paul Benedict (non-binding)

If I've left any votes out, or gotten any of the votes wrong, be sure
to chime in!

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



RE: SV: Struts 1.3 and Internationalization

2006-03-30 Thread Joe Germuska

At 7:54 AM +0200 3/30/06, <[EMAIL PROTECTED]> wrote:

Hi

And now we have come full circle: You suggest to use Strings in 
forms, but if you do - do not blame Struts?


So, lets stick with Struts, and use Double and Floats etc. We know 
that this does not work because of RequestUtils. So my statement 
stills stands: Struts does not do I18N properly.


If you use Strings in forms, then converting them to anything else is 
nothing Struts has anything to do with -- RequestUtils populates 
ActionForms, not your model objects.


That said, I think this demonstrates the inaccuracy of Don's 
assertion about how seriously Struts has always taken 
internationalization -- clearly, no one has pressed the issue, but 
the implementation is incomplete.  Having ActionForms as objects 
implies that it's OK to use non-String values, regardless of best 
practices, and those non-String values aren't handled smoothly in 
some situations.


Martin makes a good point -- even my suggestion about how to populate 
non-string properties of ActionForms doesn't address displaying them 
-- the form tags don't know enough to apply any locale sensitive 
formatting when refilling a field.  This might be something which 
could be worked out, but it makes this a bigger issue.


I think it would be great to integrate FormDef into Struts.

Can anyone explain how WebWork handles this?  I've read about the 
advanced conversion services, which look good, but I haven't quite 
seen how it handles re-displaying values in the case of conversion 
errors, and I've run out of time to trace through the code to figure 
it out for myself at the moment.


Joe




Hermod

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Martin Cooper
Sent: Thursday, March 30, 2006 7:46 AM
To: Struts Developers List
Subject: Re: SV: Struts 1.3 and Internationalization


On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


 Hi

 Martin, Hubert : I am using Strings only in my forms, and using BeanUtils
 to populate my VO's. However, consider what Joe is writing here about
 Converters and scope. Not only that, Converters are not! localeware. I have
 had to hack them in order to support a comma decimal separator



Perhaps, but doesn't that make this a BeanUtils question rather than a
Struts question? If you're doing the conversion from strings using BeanUtils
yourself, I guess I'm not sure what the relationship is to Struts and i18n.

--
Martin Cooper


from DoubleConverter.convert:


   ...
 if (value instanceof Double)
 {
 return (value);
 }
 else if (value instanceof Number)
 {
 return new Double(((Number) value).doubleValue());
 }

   if(value instanceof String)
   {
 value = ((String) value).replace('.',',');
   }
   ...

 Since the Converters implement an interface, it might be possible to
 implement them in so that they have a reference to for instance a request
 scoped class that holds a reference to the current request, and is
 instantiated by a filter. This would mean creating a very simple filter
 who's only responsibility was to get the locale from the request, and put
 this into a static ThreadLocal variable ( I do this to hold hibernate
 sessions in a pre-Spring application). This way the converter could ask that
 class to serve it the locale.

 And by the way: Referring to another project such as formdef to solve a
 problem that inherently lies within Struts does not help Struts become
 better.

 Hermod

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
 Martin Cooper
 Sent: Thursday, March 30, 2006 12:46 AM
 To: Struts Developers List
 Subject: Re: SV: Struts 1.3 and Internationalization


 On 3/29/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
 >
 > On 3/29/06, Joe Germuska <[EMAIL PROTECTED]> wrote:

 > > > I started to believe this, but now I disagree.

 > >
 > > It is only solvable with the current code if your application runs in
 > > one Locale.  Struts does not provide a way to register instantaneous
 > > conversion parameters (like the current Locale) -- registering a
 > > converter with ConvertUtils has application-wide (actually JVM-wide)
 > > scope, and would not be correct in the case that the same application
 > > was handling floats that would have different decimal separators (to
 > > use Hermod's example).
 > >
 > > The active locale must be passed in to RequestUtils.populate(...),
 > > and in this case, compatibility seems like a lame excuse.
 > >
 > > Here's where the action happens:
 > >
 > > entrance to RequestUtils.populate(...):
 > >
 >

http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341
 > >
 > > The actual place where ActionForm properties are set:
 > >
 >

http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451
 > >
 > > I see no reason why all this code couldn

DO NOT REPLY [Bug 39156] New: - [Shale] client side commons validation not working inside a dataList

2006-03-30 Thread 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=39156

   Summary: [Shale] client side commons validation not working
inside a dataList
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Overview:
I was using Shale nightly build 20060328. See
http://www.mail-archive.com/user%40struts.apache.org/msg44124.html for pertinent
mailing list discussion. For inputs inside a dataList a row index is included in
the clientId to guarantee uniqueness on the html input id's. For example
"myForm:myDataList_0:someRequiredField" for the first row,
"myForm:myDataList_1:someRequiredField" for the second, and so on. But in
the rendering of the javascript by the struts validatorScript tag, the
clientId of the input components lose their row index.

To reproduce:
Deploy the jsp file whose source is included at the end of this description into
a minimal myfaces web-app. Drop into WEB-INF/lib the shale-core dependency files
and a myfaces-1.1.1 "all" jar. 
Start the web-app and open http://localhost:8080/shale_debug/index.jsf.  Do a
view source on the html and you will see two  fields with their id's
"someForm:someDataList_0:someRequiredField" and
"someForm:someDataList_0:someRequiredField". But in the validation javascript
function required() you'll see only one input
"someForm:someDataList:someRequiredField".   If you submit the form without
filling out the required fields you will notice that a javascript error occurs
causing client side validation to be skipped. The server-side validation works 
ok.

The full list of jars you need in WEB-INF/lib is :
commons-beanutils.jar, commons-chain.jar,commons-codec-1.3.jar,
commons-digester.jar, commons-fileupload.jar, commons-logging.jar,
commons-validator.jar, shale-core.jar, myfaces-all-1.1.1.jar
 
==
The source for the index.jsp is as follows:
==
<%@ page language="java"
import="java.util.*,org.apache.shale.dialog.impl.DialogImpl"%>

<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
<%@ taglib uri="http://myfaces.apache.org/extensions"; prefix="t"%>
<%@ taglib uri="http://struts.apache.org/shale/core"; prefix="s" %>

<%
/* Put a couple of Shale DialogImpl objects into the session (we just need an
object with a getter and a setter
 * and this class is readily accessible)
 */
List inputObjects = new ArrayList();
inputObjects.add(new DialogImpl());
inputObjects.add(new DialogImpl());
session.setAttribute("someInputObjects",inputObjects);
%>



<%--
A form with a dataList of inputs. The client side id's of the components will be
someForm:someDataList_0:someRequiredField and
someForm:someDataList_1:someRequiredField
--%>

  



  


  

<%--
The dataList is now closed. Before we close out the form, write out the
validator javascript. But
this results in a mismatch on the client side id's in the required function.
Note the uniqueness
indexes _0 and _1 are missing. Because we are outside the 
dataList there is no "row index" anymore (and for some reason the HtmlInputText
components `calculate`
their clientId's again when asked for getClientId from Shale's ValidatorScript
findCommonsValidators method
Here's what the validatorScript comes up with:-
function required() { 
  this[0] = new Array("someForm:someDataList:someRequiredField", "Name is
required.", new Function("x", "return {}[x];"));
}
--%>
  

  





-- 
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 39156] - [Shale] client side commons validation not working inside a dataList

2006-03-30 Thread 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=39156





--- Additional Comments From [EMAIL PROTECTED]  2006-03-30 17:15 ---
Created an attachment (id=18006)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18006&action=view)
"war" file to be deployed in tomcat

This is a skeleton war file ready to br dropped into tomcat that reproduces the
problem. It includes the jsp and configuration files but you would need to drop
in the WEB-INF/lib files as detailed in the issue description.

-- 
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 39156] - [Shale] client side commons validation not working inside a dataList

2006-03-30 Thread 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=39156





--- Additional Comments From [EMAIL PROTECTED]  2006-03-30 17:16 ---
Try upgrading to the latest myfaces snapshot.

There were issues fixed in the last month or so dealing with input components
inside a dataList.


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



Re: [Struts Ti] XWork?

2006-03-30 Thread Eric Molitor
This may be a dumb suggestion but why not implement a lightweight action
class that's in StrutsAction and then if a user chooses they can use the
full support of XWork. I'm not sure where you draw the line (you'd probably
want validation) but I cant see why you couldn't implement a few of the
interfaces. This kind of goes along with the POJO support for actions in WW
2.2

- Eric

On 3/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> To add to that, Patrick and I were collaborating on "phase 2" type
> features before we even thought of merging projects.  After that
> brainstorming session, I started talking to Patrick about one of the
> ideas that came out of the conversion, like devMode, and Patrick
> implemented it in WebWork.  He also went on to create QuickStart, which
> allows you to quickly prototype applications without a complication
> step.  These were the types of ideas we were wanting to explore in Ti -
> ways to make the job easier for the developer.
>
> Don
>
> Ted Husted wrote:
> > I think we're all still working off the original proposal.
> >
> > * http://wiki.apache.org/struts/StrutsTi
> >
> > Don is simply referring to "phase 2", while most of us are still
> > focused on "phase 1".
> >
> > -Ted.
> >
> > On 3/30/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >
> >> Don, I think this is totally at odds with a lot of the things I've been
> >> reading lately.  Granted its been hard to separate the facts from the
> >> noise lately (through no fault of anyone involved with the merger), but
> >> even still...
> >>
> >> Can I make a suggestion?  Certainly for the sake of the users in both
> >> communities, but also to be sure those doing the work are all on the
> >> same page, I think it would be a good idea for someone to write up what
> >> the plan actually is, and make sure everyone is on board with
> it.  Maybe
> >> I'm speaking out of turn and such a thing already exists, but I really
> >> believe a lot of people are thinking this is just a Webwork rebranding,
> >> with some additions taken from Struts, and if that isn't the case I
> >> think it would be prudent to have a document than anyone can point to
> >> and say "that's what we're doing, that's the plan!".
> >>
> >> Frank
> >>
> >
> > -
> > 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: SV: Struts 1.3 and Internationalization

2006-03-30 Thread Hubert Rabago
On 3/30/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> Martin makes a good point -- even my suggestion about how to populate
> non-string properties of ActionForms doesn't address displaying them
> -- the form tags don't know enough to apply any locale sensitive
> formatting when refilling a field.  This might be something which
> could be worked out, but it makes this a bigger issue.
>
> I think it would be great to integrate FormDef into Struts.
>
> Can anyone explain how WebWork handles this?  I've read about the
> advanced conversion services, which look good, but I haven't quite
> seen how it handles re-displaying values in the case of conversion
> errors, and I've run out of time to trace through the code to figure
> it out for myself at the moment.
>
> Joe

FormDef can handle the formatting and parsing of these fields.  It's
not a replacement for ActionForms, it works using them, by taking care
of their configuration, formatting (prepopulation), and parsing (upon
form submission).

In order to handle formatting and parsing, you need to tell FormDef
what format (or converter) you want to use, and that means
configuration.

So if people were interested, there's two ways to look at this: add
FormDef as a totally independent plugin with its own XML, like
Validator and Tiles, or really integrate it, adding elements to
struts-config.

Like Joe, I'm also interested in how WebWork handles this, especially
locale-specific field formats (number, dates, etc).  I haven't reached
that chapter in WWIA yet.

Hubert

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



Re: [Struts Ti] XWork?

2006-03-30 Thread Don Brown
On what framework would this solution you are describing run?  Are you talking about running Struts 1.x actions inside 
Action 2?  If so, that is something that has been started in the sandbox, but not fully developed.  I'd like to hear more.


Don

Eric Molitor wrote:

This may be a dumb suggestion but why not implement a lightweight action
class that's in StrutsAction and then if a user chooses they can use the
full support of XWork. I'm not sure where you draw the line (you'd probably
want validation) but I cant see why you couldn't implement a few of the
interfaces. This kind of goes along with the POJO support for actions in WW
2.2

- Eric

On 3/29/06, Don Brown <[EMAIL PROTECTED]> wrote:

To add to that, Patrick and I were collaborating on "phase 2" type
features before we even thought of merging projects.  After that
brainstorming session, I started talking to Patrick about one of the
ideas that came out of the conversion, like devMode, and Patrick
implemented it in WebWork.  He also went on to create QuickStart, which
allows you to quickly prototype applications without a complication
step.  These were the types of ideas we were wanting to explore in Ti -
ways to make the job easier for the developer.

Don

Ted Husted wrote:

I think we're all still working off the original proposal.

* http://wiki.apache.org/struts/StrutsTi

Don is simply referring to "phase 2", while most of us are still
focused on "phase 1".

-Ted.

On 3/30/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:


Don, I think this is totally at odds with a lot of the things I've been
reading lately.  Granted its been hard to separate the facts from the
noise lately (through no fault of anyone involved with the merger), but
even still...

Can I make a suggestion?  Certainly for the sake of the users in both
communities, but also to be sure those doing the work are all on the
same page, I think it would be a good idea for someone to write up what
the plan actually is, and make sure everyone is on board with

it.  Maybe

I'm speaking out of turn and such a thing already exists, but I really
believe a lot of people are thinking this is just a Webwork rebranding,
with some additions taken from Struts, and if that isn't the case I
think it would be prudent to have a document than anyone can point to
and say "that's what we're doing, that's the plan!".

Frank


-
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: [Struts Ti] XWork?

2006-03-30 Thread Joe Germuska

At 8:55 AM -0800 3/30/06, Don Brown wrote:
Are you talking about running Struts 1.x actions inside Action 2? 
If so, that is something that has been started in the sandbox, but 
not fully developed.  I'd like to hear more.


Don:

where is this, exactly?  and if you have the time, what's the 
status/plan/etc?  This is something I've just started thinking about 
in the last couple of weeks, but don't want to reinvent the wheel...


Joe


--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

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



Re: [Struts Ti] XWork?

2006-03-30 Thread Don Brown
The code is in sandbox/ti/phase1/jars/legacy I believe, although I recently started moving it to sandbox/action2/legacy, 
but got stuck trying to make a Maven 2 build work.  The code is still in an exploratory stage, but there is conversion 
code to turn Action 2 objects into Action 1 equivalences, and get scoped action forms to work with Action 2, as well as 
a few other things.


Don

Joe Germuska wrote:

At 8:55 AM -0800 3/30/06, Don Brown wrote:
Are you talking about running Struts 1.x actions inside Action 2? If 
so, that is something that has been started in the sandbox, but not 
fully developed.  I'd like to hear more.


Don:

where is this, exactly?  and if you have the time, what's the 
status/plan/etc?  This is something I've just started thinking about in 
the last couple of weeks, but don't want to reinvent the wheel...


Joe





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



svn commit: r390199 - in /struts/sandbox/trunk/action2: README.txt apps/mailreader/src/java/mailreader2/Constants.java apps/mailreader/src/java/mailreader2/Welcome.java apps/mailreader/src/webapp/WEB-

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 10:05:24 2006
New Revision: 390199

URL: http://svn.apache.org/viewcvs?rev=390199&view=rev
Log:
Action2 Apps
* Mailreader Tour
** Tweaks, up to "Logon.do" 

Modified:
struts/sandbox/trunk/action2/README.txt

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=390199&r1=390198&r2=390199&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Thu Mar 30 10:05:24 2006
@@ -58,19 +58,39 @@
 
 * Other examples can be added at will.
 
+
+
 Example idea jar
 
 * See http://www.niallp.pwp.blueyonder.co.uk/strutsvalidatorextends.html
 for some validation use cases.
 
+* Display an unexpected exception on an error page. 
+** What's the conditional logic using JSP tags?
+
+* "param->prepare->param interceptor pattern"
+** http://forums.opensymphony.com/thread.jspa?threadID=23750&tstart=0
+
+* Using proxy objects to restrict access to domain objects
+** http://forums.opensymphony.com/thread.jspa?threadID=23750&tstart=0
+
+
+
+Examples that might involve new development
+
 * How do we set checkboxes false (on uncheck)?
 ** http://forums.opensymphony.com/thread.jspa?threadID=23601&tstart=0
 
 * How to set the focus on a form field?
 ** http://forums.opensymphony.com/thread.jspa?threadID=23777&tstart=0
 
-* Display an unexpected exception on an error page. 
-** What's the conditional logic using JSP tags?
+*  Populating POJO that implements an Interface 
+** http://forums.opensymphony.com/thread.jspa?threadID=23750&tstart=0
+
+*  Wizard
+** http://forums.opensymphony.com/thread.jspa?threadID=23778&tstart=15
+
+
 
 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java?rev=390199&r1=390198&r2=390199&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
 Thu Mar 30 10:05:24 2006
@@ -103,7 +103,7 @@
  * A standard key from the message resources file, to test if it is 
available.
  * 
  */
-public static final String ERRORS_REQUIRED = "errors.required";
+public static final String ERROR_DATABASE_MISSING = 
"error.database.missing";
 
 //  Log Messages 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java?rev=390199&r1=390198&r2=390199&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java 
(original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java 
Thu Mar 30 10:05:24 2006
@@ -1,9 +1,5 @@
 package mailreader2;
 
-import org.apache.struts.apps.mailreader.dao.UserDatabase;
-import com.opensymphony.xwork.Action;
-import com.opensymphony.xwork.ActionSupport;
-
 /**
  * Verify that essential resources are available.
  */
@@ -12,22 +8,21 @@
 public String execute() throws Exception {
 
 // Confirm message resources loaded
-String message = getText(Constants.ERRORS_REQUIRED);
-if (Constants.ERRORS_REQUIRED.equals(message)) {
+String message = getText(Constants.ERROR_DATABASE_MISSING);
+if (Constants.ERROR_DATABASE_MISSING.equals(message)) {
 addActionError(Constants.ERROR_MESSAGES_NOT_LOADED);
 }
 
 // Confirm database loaded
-UserDatabase database = getDatabase();
-if (null==database) {
+if (null==getDatabase()) {
  addActionError(Constants.ERROR_DATABASE_NOT_LOADED);
 }
 
 if (hasErrors()) {
-return Action.ERROR;
+return ERROR;
 }
 else {
-return ActionSupport.SUCCESS;
+return SUCCESS;
 }
 }
 }

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml?rev=390199&r1=390198&r2=390199&view=diff
=

[Struts Wiki] Trivial Update of "EventActionDispatcher" by MichaelJouravlev

2006-03-30 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/EventActionDispatcher

The comment on the change is:
Updated wording

--
  ## page was renamed from ActionDispatcher
  == Handling events with action dispatcher ==
  
- Struts is considered to be a simple request/response framework with no notion 
of events. This is not exactly true. It is possible to assign events to input 
elements of an HTML form or evnt to regular links, and to process these events 
in a uniform fashion by a single action class.
+ It is commonly accepted that Struts has no concept of events. This is not 
true, it is possible to assign events to input elements of an HTML form or even 
to regular links, and to process these events in a uniform fashion by a single 
action class.
  
- == Dispatch actions ==
+ == Dispatcher Actions ==
  
- Struts distribution includes several action classes that can accept several 
events and dispatch them to corresponding method handler. These actions are: 
!DispatchAction, !LookupDispatchAction and !MappingDispatchAction. These 
classes are not perfect though.
+ Struts distribution includes dispatcher action classes that send input events 
to their respective handlers in an action class. These actions are: 
!DispatchAction, !LookupDispatchAction and !MappingDispatchAction. These 
classes are not perfect and show their age:
  
-* An action class must extend one of these classes to use dispatch 
features.
+* User's custom action class must extend one of these classes to use 
dispatch features.
-* !DispatchAction requires submit button caption to be the same as handler 
method name.
+* !DispatchAction requires submit button caption to be the same as handler 
method name; usage of an arbitrary caption requires Javascript.
 * !LookupDispatchAction uses reverse lookup to property file and requires 
button-to-method map; button caption cannot be changed without application 
restart.
 * !MappingDispatchAction can process only one event per action mapping 
definition, so you have one class but several action mappings and several URLs.
  
@@ -19, +19 @@

  == Action Dispatcher ==
  Struts 1.2.7+ distribution includes !ActionDispatcher class that combines 
features of all dispatch actions. It allows to select a particular behavior or 
flavor and, what is the most appealing, it allows to dispatch events to any 
action class.
  
- !ActionDispatcher does not improve event-handling features of the three 
aforementioned dispatch classes, so it has been extended. The extended version 
is called EventActionDispatcher. It is included in Struts 1.2.9 and 1.3.1+ and 
solves all known dispatch issues:
+ Struts 1.2.9 and 1.3.1+ contains the extended version of !ActionDispatcher 
called !EventActionDispatcher. It solves all known dispatch issues:
  
 * Any arbitrary action class can handle several events.
 * One action mapping can contain several event definitions.
-* Submit buttons can have any caption; caption can be changed in runtime.
+* Submit buttons can have any caption; caption can be changed in runtime; 
Javascript is not required.
-* No event-to-method map is needed.
+* No event-to-method or property-to-caption map is needed.
-* Action method name can be either used directly on a web page, or can be 
aliased with an event name.
+* Submit button or a link can either directly refer to action method name, 
or can use a separate event name as an alias; aliases are defined in 
"parameter" attribute of action mapping.
-* It is possible to define a default method if event is not recognized.
+* It is possible to specify a default method if event is not recognized in 
the request.
-* If event is not recognized and default method is not defined, the 
dispatcher invokes {{{unspecified}}} method.
+* If event is not recognized and default method is not specified, the 
dispatcher invokes {{{unspecified}}} method.
 * Standard Cancel buttons is hooked up to {{{cancelled}}} method and does 
not have to be defined explicitly.
  
  == Dispatching events using EventActionDispatcher ==
  
+ Dispatching events with !EventActionDispatcher is easy. Usually you will 
define two action classes: ''submit action'' will handle all input events , 
while ''setup/render action'' will choose an appropriate page and display it. 
!EventActionDispatcher allows you to combine both input and render functions in 
one class as well.
- Dispatching events is now easy. Usually, you will define two action classes: 
''submit action'' will handle all input events , while ''setup/render action'' 
will choose an appropriate page and display it. In some cases you can get by 
with only one action that handles events as well as renders a view. 
- 
- Below is shown how to us

Re: [Struts Ti] XWork?

2006-03-30 Thread Eric Molitor
Well what I've been toying with is two things the first isn't directly
related but might be of interest.

At the SpringExperience there were some discussions about integrating
SpringWebflow into webwork and I started playing with some code. What I
ended up with was a weird WebFlowAction that could (semi) invoke a webflow.
It was far form perfect and I eventually lost interest. A week or so ago I
took the same idea and started writing a StrutsAction Action. Basically the
action just invokes the execute method of the struts action using
ServletActionContext.getResponse() and ServletActionContext.getRequest() to
supply the necessary parameters. There is a getActionForward() method for
getting the Struts Action result and the return is hardcoded to "SUCCESS".
I don't know how valid this is but I've been able to execute some synthetic
tests with positive results. The next bit I was planning on trying was using
reflection to invoke all the getter methods on the Struts Action and then
manually pushing them onto the stack. My reasoning for doing all of this was
to provide a way to invoke StrutsActions within an unmodified WebWork 2.2.

Now back to what you really asked for, any pojo is an action, why not just
write a custom dispatcher for invoking legacy Struts Actions and maybe
create a new execute method such as...

Public String execute(ActionMapping mapping, ActionForm form)

I probably should just start coding some of this up for people to look at as
I communicate much better that way. After rereading the email I don't think
I've clarified anything. But hey I'll send it anyway and try to get on the
WebWork chat server later to try to explain it a bit more logically.

- Eric



On 3/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> On what framework would this solution you are describing run?  Are you
> talking about running Struts 1.x actions inside
> Action 2?  If so, that is something that has been started in the sandbox,
> but not fully developed.  I'd like to hear more.
>
> Don
>
> Eric Molitor wrote:
> > This may be a dumb suggestion but why not implement a lightweight action
> > class that's in StrutsAction and then if a user chooses they can use the
> > full support of XWork. I'm not sure where you draw the line (you'd
> probably
> > want validation) but I cant see why you couldn't implement a few of the
> > interfaces. This kind of goes along with the POJO support for actions in
> WW
> > 2.2
> >
> > - Eric
> >
> > On 3/29/06, Don Brown < [EMAIL PROTECTED]> wrote:
> >> To add to that, Patrick and I were collaborating on "phase 2" type
> >> features before we even thought of merging projects.  After that
> >> brainstorming session, I started talking to Patrick about one of the
> >> ideas that came out of the conversion, like devMode, and Patrick
> >> implemented it in WebWork.  He also went on to create QuickStart, which
>
> >> allows you to quickly prototype applications without a complication
> >> step.  These were the types of ideas we were wanting to explore in Ti -
> >> ways to make the job easier for the developer.
> >>
> >> Don
> >>
> >> Ted Husted wrote:
> >>> I think we're all still working off the original proposal.
> >>>
> >>> * http://wiki.apache.org/struts/StrutsTi
> >>>
> >>> Don is simply referring to "phase 2", while most of us are still
> >>> focused on "phase 1".
> >>>
> >>> -Ted.
> >>>
> >>> On 3/30/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >>>
>  Don, I think this is totally at odds with a lot of the things I've
> been
>  reading lately.  Granted its been hard to separate the facts from the
>  noise lately (through no fault of anyone involved with the merger),
> but
>  even still...
> 
>  Can I make a suggestion?  Certainly for the sake of the users in both
>  communities, but also to be sure those doing the work are all on the
>  same page, I think it would be a good idea for someone to write up
> what
>  the plan actually is, and make sure everyone is on board with
> >> it.  Maybe
>  I'm speaking out of turn and such a thing already exists, but I
> really
>  believe a lot of people are thinking this is just a Webwork
> rebranding,
>  with some additions taken from Struts, and if that isn't the case I
>  think it would be prudent to have a document than anyone can point to
>  and say "that's what we're doing, that's the plan!".
> 
>  Frank
> 
> >>> -
> >>> 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: [Struts Ti] XWork?

2006-03-30 Thread Don Brown
Sure, a custom ActionInvocation instance could even invoke a Struts Action as is.  The question is how you handle 
ActionForms.  Do you implement the Struts request processing chain as Interceptors?  Add an Interceptor that calls a 
chain?  Action 2 already has the DefaultWorkflowInterceptor which defines the basic validation workflow, so it would be 
easy to create one that implemented a Struts 1.x workflow.


Again, we've kinda started down this path in the sandbox.  Take a look at that code and see if you can find anything 
that might be helpful.  This is exactly the type of migration library we had in mind for our first release, so your help 
will be big.


Don

Eric Molitor wrote:

Well what I've been toying with is two things the first isn't directly
related but might be of interest.

At the SpringExperience there were some discussions about integrating
SpringWebflow into webwork and I started playing with some code. What I
ended up with was a weird WebFlowAction that could (semi) invoke a webflow.
It was far form perfect and I eventually lost interest. A week or so ago I
took the same idea and started writing a StrutsAction Action. Basically the
action just invokes the execute method of the struts action using
ServletActionContext.getResponse() and ServletActionContext.getRequest() to
supply the necessary parameters. There is a getActionForward() method for
getting the Struts Action result and the return is hardcoded to "SUCCESS".
I don't know how valid this is but I've been able to execute some synthetic
tests with positive results. The next bit I was planning on trying was using
reflection to invoke all the getter methods on the Struts Action and then
manually pushing them onto the stack. My reasoning for doing all of this was
to provide a way to invoke StrutsActions within an unmodified WebWork 2.2.

Now back to what you really asked for, any pojo is an action, why not just
write a custom dispatcher for invoking legacy Struts Actions and maybe
create a new execute method such as...

Public String execute(ActionMapping mapping, ActionForm form)

I probably should just start coding some of this up for people to look at as
I communicate much better that way. After rereading the email I don't think
I've clarified anything. But hey I'll send it anyway and try to get on the
WebWork chat server later to try to explain it a bit more logically.

- Eric



On 3/30/06, Don Brown <[EMAIL PROTECTED]> wrote:

On what framework would this solution you are describing run?  Are you
talking about running Struts 1.x actions inside
Action 2?  If so, that is something that has been started in the sandbox,
but not fully developed.  I'd like to hear more.

Don

Eric Molitor wrote:

This may be a dumb suggestion but why not implement a lightweight action
class that's in StrutsAction and then if a user chooses they can use the
full support of XWork. I'm not sure where you draw the line (you'd

probably

want validation) but I cant see why you couldn't implement a few of the
interfaces. This kind of goes along with the POJO support for actions in

WW

2.2

- Eric

On 3/29/06, Don Brown < [EMAIL PROTECTED]> wrote:

To add to that, Patrick and I were collaborating on "phase 2" type
features before we even thought of merging projects.  After that
brainstorming session, I started talking to Patrick about one of the
ideas that came out of the conversion, like devMode, and Patrick
implemented it in WebWork.  He also went on to create QuickStart, which
allows you to quickly prototype applications without a complication
step.  These were the types of ideas we were wanting to explore in Ti -
ways to make the job easier for the developer.

Don

Ted Husted wrote:

I think we're all still working off the original proposal.

* http://wiki.apache.org/struts/StrutsTi

Don is simply referring to "phase 2", while most of us are still
focused on "phase 1".

-Ted.

On 3/30/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:


Don, I think this is totally at odds with a lot of the things I've

been

reading lately.  Granted its been hard to separate the facts from the
noise lately (through no fault of anyone involved with the merger),

but

even still...

Can I make a suggestion?  Certainly for the sake of the users in both
communities, but also to be sure those doing the work are all on the
same page, I think it would be a good idea for someone to write up

what

the plan actually is, and make sure everyone is on board with

it.  Maybe

I'm speaking out of turn and such a thing already exists, but I

really

believe a lot of people are thinking this is just a Webwork

rebranding,

with some additions taken from Struts, and if that isn't the case I
think it would be prudent to have a document than anyone can point to
and say "that's what we're doing, that's the plan!".

Frank


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




--

svn commit: r390220 - /incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java

2006-03-30 Thread mrdon
Author: mrdon
Date: Thu Mar 30 11:21:39 2006
New Revision: 390220

URL: http://svn.apache.org/viewcvs?rev=390220&view=rev
Log:
Fixing Spring object factory not loading correctly due to new class name

Modified:

incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java

Modified: 
incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java?rev=390220&r1=390219&r2=390220&view=diff
==
--- 
incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java
 (original)
+++ 
incubator/webwork2/src/java/org/apache/struts/action2/dispatcher/DispatcherUtils.java
 Thu Mar 30 11:21:39 2006
@@ -104,7 +104,7 @@
 if (className.equals("spring")) {
 // note: this class name needs to be in string form so we 
don't put hard
 //   dependencies on spring, since it isn't technically 
required.
-className = 
"org.apache.struts.action2.spring.WebWorkSpringObjectFactory";
+className = 
"org.apache.struts.action2.spring.StrutsSpringObjectFactory";
 } else if (className.equals("plexus")) {
 // note: this class name needs to be in string form so we 
don't put hard
 //   dependencies on spring, since it isn't technically 
required.



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



Re: [Struts Ti] XWork?

2006-03-30 Thread Joe Germuska

At 11:07 AM -0800 3/30/06, Don Brown wrote:
Sure, a custom ActionInvocation instance could even invoke a Struts 
Action as is.  The question is how you handle ActionForms.  Do you 
implement the Struts request processing chain as Interceptors?  Add 
an Interceptor that calls a chain?  Action 2 already has the 
DefaultWorkflowInterceptor which defines the basic validation 
workflow, so it would be easy to create one that implemented a 
Struts 1.x workflow.


My idea was to implement the Struts RP chain as interceptors.  I 
haven't gotten too far on this, but that's the motivation behind my 
interest in factoring out the Struts initialization from 
ActionServlet into a ServletContextListener.



 Bug 39040 - Refactor Struts initialization to ServletContextListener
 http://issues.apache.org/bugzilla/show_bug.cgi?id=39040


I haven't gotten very far on this, but if a few of us are thinking 
about variations on this, now's the time for level-setting.


Again, we've kinda started down this path in the sandbox.  Take a 
look at that code and see if you can find anything that might be 
helpful.  This is exactly the type of migration library we had in 
mind for our first release, so your help will be big.


I haven't yet had a chance to look at this myself.

Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

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



Re: [Struts Ti] XWork?

2006-03-30 Thread Gabe

Don,

I was refering to phase I really, whether the starting point is Webwork or 
Webwork + XWork. 

Also, it seems from the documents on the project (if I am not incorrect) that 
XWork would still be a strong part of phase II and that there are Struts 
centric modifications to it that we might want to do, which strengthens the 
move over now argument.

Also, could you clarify:
"The first Ti prototype was going to be built on XWork, but I ended up 
just using WebWork itself since it did everything I wanted and was very 
easy to build upon."

Does that mean that you removed the XWork dependancy from the Ti prototype or 
that you included WW in addition to XWork?

Thanks,
Gabe

- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Thursday, March 30, 2006 12:22:01 AM
Subject: Re: [Struts Ti] XWork?

Gabe wrote:
> I wanted to answer these two comments by Ted. Whether to bring XWork is a 
> very important decision to make ASAP, because it is about how we define 
> Struts Action 2.0.
>
> Struts Action 2.0 = Webwork
>
> - or -
>
> Struts Action 2.0 = Webwork + XWork
>   
While I'll let other XWork/WebWork folks weigh in on the XWork issue, I 
want to quickly make the point that this equation is incorrect.  The 
original vision of Struts Action 2.0 started as Struts Ti.  It was a 
collaboration of Beehive, WebWork, and Struts folks looking to write a 
simplified, Action 2 framework that leveraged the strengths of each.  
The first Ti prototype was going to be built on XWork, but I ended up 
just using WebWork itself since it did everything I wanted and was very 
easy to build upon.  Spring was included into the discussion and soon 
"Clarity" was born with the idea of merging the four frameworks, however 
that proved too big of task for those involved.  Ted threw out the idea 
to WebWork for their team to merge forces and work on Ti, and that's how 
the merger started.

 From the beginning, the goal was to create a project that simplified 
the developers task of writing web apps though less configuration and 
more modern features, and combining efforts is how we plan to accomplish 
this.  While yes, we might hold off on new fancy features for now so we 
can get the first versions out quickly to the community, the goal was 
not and has never been a simple "rebranding" of WebWork.

I'm sure you didn't mean it that way, but I wanted to take this 
opportunity and correct a misconception that seems to be going on around 
this project.  Our goal is to create a new simpler, more feature-rich, 
developer-oriented framework leveraging all we've learned from Struts, 
WebWork, and other frameworks out there.

Carry on :)

Don

-
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: [Struts Ti] XWork?

2006-03-30 Thread Ted Husted
On 3/30/06, Gabe <[EMAIL PROTECTED]> wrote:
>
> Don,
>
> I was refering to phase I really, whether the starting point is Webwork or 
> Webwork + XWork.

I think Don is saying that it would be helpful to see a concrete
proposal from the XWork developers that outlines what they would like
to do. Once the set of XWork developers weigh in, we can continue the
discussion. But, it is not appropriate for us to have the discussion
here. We have no idea of how many XWork developers are following this
thread. The starting point is the XWork community.

It's interesting to note that Struts Action 1.3 has a similar
dependency on Commons Chain. The XWork dependency is more extreme, but
it is the same sort of thing. For Commons Chain, we chose to set it up
as an independant project in the Jakarta Commons, so that it would be
available to other projects too. Of course, we did the same thing with
a great number of Action 1 dependencies, like BeanUtils, Validator,
and so on.

I'm aware that at least one other project is using XWork, and if it
came out from under the WebWork shadow, them other projects might find
it useful too.

Even just here, Craig has mentioned that we might be able to use XWork
Interceptors as part of Shale. If we tightly bind XWork to Action2, it
may make it easier for Action 2 to use, but it would make it
correspondingly harder for for other projects to use XWork.

But, again, the place to have this conversation is at OpenSymphony,
where the XWork community can fully participate.

-Ted.

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



svn commit: r390256 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/java/ apps/mailreader/src/java/mailreader2/ apps/mailreader/src/webapp/pages/

2006-03-30 Thread husted
Author: husted
Date: Thu Mar 30 14:08:42 2006
New Revision: 390256

URL: http://svn.apache.org/viewcvs?rev=390256&view=rev
Log:
Action2 Apps
* README - Add notes for new cookbook examples and new features (culled from WW 
Forum)
* Mailreader Tour
** Up to Logon-validation.xml 


Modified:
struts/sandbox/trunk/action2/README.txt

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=390256&r1=390255&r2=390256&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Thu Mar 30 14:08:42 2006
@@ -74,6 +74,25 @@
 * Using proxy objects to restrict access to domain objects
 ** http://forums.opensymphony.com/thread.jspa?threadID=23750&tstart=0
 
+* Using an authentification interceptor. 
+** 
+
+* Overriding a bundled UI Tag. 
+
+* Creating a custom UI Tag.
+
+* Canceling a form with client-side validation.
+** (Should there be a "validate" attribute to generate the 
"form.onsubmit=null" script?)
+** (Should ActionSupport provide "public String cancel() {return CANCEL;} ?
+** (Should we support action="!cancel" to be consistent with form tag.)
+*** (Trying !cancel in WW2.2.2 carries cancel over to the next action.)
+
+* Setting form type to "POST"
+** (Should POST be the default?)
+
+* DRY UI Tags 
+** http://forums.opensymphony.com/thread.jspa?threadID=24140&tstart=0
+
 
 
 Examples that might involve new development

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java?rev=390256&r1=390255&r2=390256&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Constants.java
 Thu Mar 30 14:08:42 2006
@@ -26,6 +26,11 @@
 // --- Tokens 
 
 /**
+ *  The token representing a "cancel" request. 
+ */
+public static final String CANCEL = "cancel";
+
+/**
  *  The token representing a "create" task. 
  */
 public static final String CREATE = "Create";

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java?rev=390256&r1=390255&r2=390256&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/MailreaderSupport.java
 Thu Mar 30 14:08:42 2006
@@ -52,6 +52,15 @@
 public class MailreaderSupport extends ActionSupport
 implements SessionAware, ApplicationAware {
 
+/**
+ * Return CANCEL so apropriate result can be selected.
+ * @return "cancel" so apropriate result can be selected.
+ */
+public String cancel() {
+return Constants.CANCEL;
+}
+
+
 //  ApplicationAware 
 
 /**

Modified: struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml?rev=390256&r1=390255&r2=390256&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml (original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml Thu Mar 30 
14:08:42 2006
@@ -52,6 +52,7 @@
 MainMenu
 /pages/Logon.jsp
 ChangePassword
+Welcome
 
 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp?rev=390256&r1=390255&r2=390256&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp Thu 
Mar 30 14:08:42 2006
@@ -15,13 +15,13 @@
 
 
 
-
+
 
 
 
 
 
-
 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.ht

[Proposal] Dissolve the Struts Flow subproject

2006-03-30 Thread Don Brown
I propose that we dissolve the Struts Flow subproject, moving it into the sandbox.  I'm saddened to write this because 
I'm still very excited about the possibilities of using continuations and Javascript at the server controller level, but 
I just don't see me having the time to create a proper release in the near future, and spend the time to create a 
vibrant community.  If and when I do create a release and it gains a following, I might propose it is accepted again as 
a subproject.


While I do like the freedom of having subprojects, I feel we must be diligent to ensure each are absolutely necessary. 
In this case, I feel it is a distraction from the other great, active projects going on, so I think moving it to the 
sandbox is the right decision at the moment.


Don

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



Re: [Struts Ti] XWork?

2006-03-30 Thread Don Brown

Gabe wrote:

Don,

I was refering to phase I really, whether the starting point is Webwork or Webwork + XWork. 


Also, it seems from the documents on the project (if I am not incorrect) that 
XWork would still be a strong part of phase II and that there are Struts 
centric modifications to it that we might want to do, which strengthens the 
move over now argument.

Also, could you clarify:
"The first Ti prototype was going to be built on XWork, but I ended up 
just using WebWork itself since it did everything I wanted and was very 
easy to build upon."


Does that mean that you removed the XWork dependancy from the Ti prototype or 
that you included WW in addition to XWork?


If you depend on WebWork, you need XWork.  Initially, I was going to just use XWork as a sign of good faith, but as I 
started using it and looking at WebWork, it turned out to do all the lower level stuff I wanted, so I was free to try 
new ideas much quicker.


Don



Thanks,
Gabe

- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Thursday, March 30, 2006 12:22:01 AM
Subject: Re: [Struts Ti] XWork?

Gabe wrote:

I wanted to answer these two comments by Ted. Whether to bring XWork is a very 
important decision to make ASAP, because it is about how we define Struts 
Action 2.0.

Struts Action 2.0 = Webwork

- or -

Struts Action 2.0 = Webwork + XWork
  
While I'll let other XWork/WebWork folks weigh in on the XWork issue, I 
want to quickly make the point that this equation is incorrect.  The 
original vision of Struts Action 2.0 started as Struts Ti.  It was a 
collaboration of Beehive, WebWork, and Struts folks looking to write a 
simplified, Action 2 framework that leveraged the strengths of each.  
The first Ti prototype was going to be built on XWork, but I ended up 
just using WebWork itself since it did everything I wanted and was very 
easy to build upon.  Spring was included into the discussion and soon 
"Clarity" was born with the idea of merging the four frameworks, however 
that proved too big of task for those involved.  Ted threw out the idea 
to WebWork for their team to merge forces and work on Ti, and that's how 
the merger started.


 From the beginning, the goal was to create a project that simplified 
the developers task of writing web apps though less configuration and 
more modern features, and combining efforts is how we plan to accomplish 
this.  While yes, we might hold off on new fancy features for now so we 
can get the first versions out quickly to the community, the goal was 
not and has never been a simple "rebranding" of WebWork.


I'm sure you didn't mean it that way, but I wanted to take this 
opportunity and correct a misconception that seems to be going on around 
this project.  Our goal is to create a new simpler, more feature-rich, 
developer-oriented framework leveraging all we've learned from Struts, 
WebWork, and other frameworks out there.


Carry on :)

Don

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



Struts Roadmap

2006-03-30 Thread Michael Jouravlev
Should not the roadmap page be revised?[1] Do commiters expect any
other versions in 1.x generation besides 1.3.x? I guess the answer is
"Yes, if something happens and it will be needed, or if someone steps
up to do it just for kicks". But should not the roadmap reflect
situation when "nothing happens"? So, what about future of 1.4+
versions, and also Struts Jericho, which is labelled as a proposal for
Struts 2.0?

[1] Struts roadmap: http://struts.apache.org/struts-action/roadmap.html

P.S. Should I file a documentation bug/ticket?

Michael.

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



Re: Struts Roadmap

2006-03-30 Thread Ted Husted
As Martin pointed out in another thread, many people, including
several committers, have Struts Action 1.3 applications in production.
The heavy lifting is done, and a initial 1.3.0 build  is available for
testing. It's just a matter of someone finding the time to wrap up the
1.3.1 release plans, and call for a quality vote.

* http://wiki.apache.org/struts/StrutsReleasePlans

Earlier today, Hubert indicated that he might finally contribute
FormDef. If that happens, I'd sure it would be a tipping point for the
Action 1.3 series.

As for Action 1.4 and beyond, if Strecks is as good as it sounds,

* http://www.realsolve.co.uk/site/strecks/

a "tiger" release of Action 1.x that put Java 5 features to good use
might be reason enough for someone to start another release series.

It's not usual for mature, stable projects with a large installed base
to continue parallel lines of development for months and even years.
We're being careful in the packaging of Action 2.0 so that we will be
able to use both major versions side-by-side.

-Ted.

On 3/30/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> Should not the roadmap page be revised?[1] Do commiters expect any
> other versions in 1.x generation besides 1.3.x? I guess the answer is
> "Yes, if something happens and it will be needed, or if someone steps
> up to do it just for kicks". But should not the roadmap reflect
> situation when "nothing happens"? So, what about future of 1.4+
> versions, and also Struts Jericho, which is labelled as a proposal for
> Struts 2.0?
>
> [1] Struts roadmap: http://struts.apache.org/struts-action/roadmap.html
>
> P.S. Should I file a documentation bug/ticket?
>
> Michael.

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



Re: [Proposal] Dissolve the Struts Flow subproject

2006-03-30 Thread Martin Cooper
On 3/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> I propose that we dissolve the Struts Flow subproject, moving it into the
> sandbox.  I'm saddened to write this because
> I'm still very excited about the possibilities of using continuations and
> Javascript at the server controller level, but
> I just don't see me having the time to create a proper release in the near
> future, and spend the time to create a
> vibrant community.  If and when I do create a release and it gains a
> following, I might propose it is accepted again as
> a subproject.
>
> While I do like the freedom of having subprojects, I feel we must be
> diligent to ensure each are absolutely necessary.
> In this case, I feel it is a distraction from the other great, active
> projects going on, so I think moving it to the
> sandbox is the right decision at the moment.


That would be OK with me. Recent goings-on at Jakarta Commons have led the
way on this type of change, so it's not unheard of. And perhaps by the time
someone has the energy to pick it up again, we'll have a more favourable
ruling on using NPL libraries too. ;-)

--
Martin Cooper


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


DO NOT REPLY [Bug 35389] - [taglib] equal tag doesn't work with huge numbers

2006-03-30 Thread 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=35389





--- Additional Comments From [EMAIL PROTECTED]  2006-03-31 06:04 ---
I'm kind of thinking always doing a String compare is the correct thing as well.
 We could use BigDecimal, but then it would break (and currently breaks, if I'm
guessing right) for some locales.  I think there should be a separate tag or at
least an attribute that sets this equal into "double" model.  Regardless, this
needs more discussion before we do anything about it in the nearterm.

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



svn commit: r390327 - /struts/taglib/trunk/src/tld/struts-html.tld

2006-03-30 Thread mrdon
Author: mrdon
Date: Thu Mar 30 21:10:28 2006
New Revision: 390327

URL: http://svn.apache.org/viewcvs?rev=390327&view=rev
Log:
Enabling EL on dynamicJavascript attribute in javascript tag
PR: 35895

Modified:
struts/taglib/trunk/src/tld/struts-html.tld

Modified: struts/taglib/trunk/src/tld/struts-html.tld
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/tld/struts-html.tld?rev=390327&r1=390326&r2=390327&view=diff
==
--- struts/taglib/trunk/src/tld/struts-html.tld (original)
+++ struts/taglib/trunk/src/tld/struts-html.tld Thu Mar 30 21:10:28 2006
@@ -3920,7 +3920,7 @@
 
 dynamicJavascript
 false
-false
+true
 
 

DO NOT REPLY [Bug 35895] - Attributes with false in TLD prevent EL evaluation

2006-03-30 Thread 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=35895


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Taglibs |Tiles
   Target Milestone|--- |1.3.1




--- Additional Comments From [EMAIL PROTECTED]  2006-03-31 06:12 ---
Ok, I added EL for the dynamicJavascript attribute [390327], but leaving the
'id' attribute for the reasons Craig mentioned.  Bumping this ticket over to
tiles...

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



svn commit: r390335 - in /struts/action/trunk/src: java/org/apache/struts/action/ActionRedirect.java test/org/apache/struts/action/TestActionRedirect.java

2006-03-30 Thread mrdon
Author: mrdon
Date: Thu Mar 30 21:43:56 2006
New Revision: 390335

URL: http://svn.apache.org/viewcvs?rev=390335&view=rev
Log:
Adding anchor support, method chaining, and better ActionForward copying to 
ActionRedirect.
Thanks to Frank W. Zammetti and Christopher Schultz for the analysis and 
patches!
PR: 36037
BTW, sorry about the ActionRedirect diff, had problems with line endings

Modified:
struts/action/trunk/src/java/org/apache/struts/action/ActionRedirect.java

struts/action/trunk/src/test/org/apache/struts/action/TestActionRedirect.java

Modified: 
struts/action/trunk/src/java/org/apache/struts/action/ActionRedirect.java
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/src/java/org/apache/struts/action/ActionRedirect.java?rev=390335&r1=390334&r2=390335&view=diff
==
--- struts/action/trunk/src/java/org/apache/struts/action/ActionRedirect.java 
(original)
+++ struts/action/trunk/src/java/org/apache/struts/action/ActionRedirect.java 
Thu Mar 30 21:43:56 2006
@@ -1,300 +1,344 @@
-/*
- * $Id$
- *
- * Copyright 2000-2004 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.struts.action;
-
-import org.apache.commons.logging.Log;
-import org.apache.commons.logging.LogFactory;
-import org.apache.struts.config.ForwardConfig;
-import org.apache.struts.util.ResponseUtils;
-
-import java.util.ArrayList;
-import java.util.Arrays;
-import java.util.HashMap;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Map;
-
-/**
- *  A subclass of [EMAIL PROTECTED] ActionForward} which is designed for 
use in
- * redirecting requests, with support for adding parameters at runtime. 
- * An [EMAIL PROTECTED] ForwardConfig} (or subclass) can be passed to the 
constructor to
- * copy its configuration:  
- * 
- * public ActionForward execute(ActionMapping mapping,
- *  ActionForm form,
- *  HttpServletRequest request,
- *  HttpServletResponse response)
- * throws Exception {
- * ActionRedirect redirect =
- * new ActionRedirect(mapping.findForward("doRedirect"));
- * redirect.addParameter("param1","value1");
- * redirect.addParameter("param2","2");
- * redirect.addParameter("param3","3.0");
- * return redirect;
- * }
- * 
- * 
- *
- * @version $Rev$ $Date$
- */
-public class ActionRedirect extends ActionForward {
-// - Manifest constants
-
-/**
- * Default allocation size for string buffers.
- */
-private static final int DEFAULT_BUFFER_SIZE = 256;
-
-// - Static variables
-
-/**
- * Commons logging instance.
- */
-protected static final Log LOG = LogFactory.getLog(ActionRedirect.class);
-
-// - Instance variables
-
-/**
- * Holds the redirect parameters. Each entry is either a String or a
- * String[] depending on whether it has one or more entries.
- */
-protected Map parameterValues = null;
-
-// - Constructors
-
-/**
- * Construct a new instance with redirect set to true and initialize
- * parameter lists.
- */
-public ActionRedirect() {
-setRedirect(true);
-initializeParameters();
-}
-
-/**
- * Construct a new instance with the specified path and initialize
- * parameter lists.
- *
- * @param path Path for this instance
- */
-public ActionRedirect(String path) {
-super(path);
-setRedirect(true);
-initializeParameters();
-}
-
-/**
- * Construct a new instance with the specified values and initialize
- * parameter lists.
- *
- * @param name   Name of this instance
- * @param path   Path for this instance
- * @param module Module prefix, if any
- */
-public ActionRedirect(String name, String path, String module) {
-super(name, path, true);
-setModule(module);
-initializeParameters();
-}
-
-/**
- * Construct a new instance with a [EMAIL PROTECTED] ForwardConfig} 
object to copy
- * name, path, and contextRelative values from.
- *
- * @param baseConfig the [EMAIL PROTECTED] ForwardConfig

DO NOT REPLY [Bug 36037] - Allow query strings and anchors when returning forwards from Action

2006-03-30 Thread 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=36037


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Unknown |Action
 Resolution||FIXED
   Target Milestone|--- |TBD




--- Additional Comments From [EMAIL PROTECTED]  2006-03-31 06:48 ---
Thanks everyone for the good ideas and code!  I resolved this issue in changeset
390335

-- 
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 38964] - [taglib] Postback Forms - Caching and Modules

2006-03-30 Thread 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=38964


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|--- |1.3.1




--- Additional Comments From [EMAIL PROTECTED]  2006-03-31 06:50 ---
Definitely needs to be looked at before the next release.  Any solutions?

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



[Struts Wiki] Update of "StrutsTaglibRelease131" by DonBrown

2006-03-30 Thread Apache Wiki
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsTaglibRelease131

The comment on the change is:
Updating tickets, removing N/A tickets

--
  
  
  || '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35389 35389] || 
[taglib] equal tag doesn't work with huge numbers  || Custom Tags  || Patch 
Available ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35895 35895] || 
Attributes with false in TLD p...  || Custom Tags  
|| Apply as to Tiles attribute ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35895 35895] || 
Attributes with false in TLD p...  || Custom Tags  
|| (./) ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=36037 36037] || Allow 
query strings and anchors when returning forwards from Action || Custom Tags || 
Patch Available ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=38964 38964] || 
Postback Forms - Caching and Modules || Custom Tags ||  ||
  
  == Preparation Checklist ==

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



Re: SV: Struts 1.3 and Internationalization

2006-03-30 Thread Rene Gielen
Joe,

see below

Joe Germuska schrieb:
> At 7:54 AM +0200 3/30/06, <[EMAIL PROTECTED]> wrote:
> 
>> Hi
>>
>> And now we have come full circle: You suggest to use Strings in forms,
>> but if you do - do not blame Struts?
>>
>> So, lets stick with Struts, and use Double and Floats etc. We know
>> that this does not work because of RequestUtils. So my statement
>> stills stands: Struts does not do I18N properly.
> 
> 
> If you use Strings in forms, then converting them to anything else is
> nothing Struts has anything to do with -- RequestUtils populates
> ActionForms, not your model objects.
> 
> That said, I think this demonstrates the inaccuracy of Don's assertion
> about how seriously Struts has always taken internationalization --
> clearly, no one has pressed the issue, but the implementation is
> incomplete.  Having ActionForms as objects implies that it's OK to use
> non-String values, regardless of best practices, and those non-String
> values aren't handled smoothly in some situations.
> 

Just for my understanding: could it be that this is more about l10n than
i18n? When it comes to validation/conversion, mostly l10n is an issue...

> Martin makes a good point -- even my suggestion about how to populate
> non-string properties of ActionForms doesn't address displaying them --
> the form tags don't know enough to apply any locale sensitive formatting
> when refilling a field.  This might be something which could be worked
> out, but it makes this a bigger issue.
> 
> I think it would be great to integrate FormDef into Struts.
> 
> Can anyone explain how WebWork handles this?  I've read about the
> advanced conversion services, which look good, but I haven't quite seen
> how it handles re-displaying values in the case of conversion errors,
> and I've run out of time to trace through the code to figure it out for
> myself at the moment.
> 

In WebWork, validation and conversion errors are available in your
valueStack after the needed mechanisms took place. Typically, the ui
themed widgets will then feel responsible for bringing the messages to
front. The standard ui themes provided with distro will render any error
message beside the input field it belongs to, with a changeable css layout.

Standard validation will validate the submitted form and redirect to
redisplay the form view with rendered error messages, in a typical
request-response manner. There is also the option to use client side
validation (pure js) and AJAX validation, both leading to on-the-fly
validation and error diplaying on onblur-events of your inputs. To
activate eg. AJAX validation, you just need to use the ajax ui theme,
and you're basically done.

References:
http://wiki.opensymphony.com/display/WW/Validation
http://wiki.opensymphony.com/display/WW/Type+Conversion
http://wiki.opensymphony.com/display/WW/Internationalization

Regards,
Rene

> Joe
> 
> 
> 
>> Hermod
>>

-- 
Rene Gielen  | http://it-neering.net/
Aachen   | PGP-ID: BECB785A
Germany  | gielen at it-neering.net

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



Towards a stable 1.3 release

2006-03-30 Thread Don Brown
Ok, as I understand the current system, we'd need a GA release of all 
the subprojects, including Action 1, in order to declare a GA 1.3 release.


How much work does those involved think this will be?  If a bit, I'm 
thinking it might be easier in the long run to go ahead, consolidate the 
subprojects, and even merge a few like taglibs and EL.  Then, we can 
push for a single release instead of having to roll and evaluate the 6  
subprojects, each might take a few releases to get GA.


I'm willing to defer to those who have been doing all the hard work to 
get this far, and I'd like to help do whatever it takes to get a stable 
release out there.  I'm just wondering if one larger release will be 
quicker and easier than 6 releases.  In fact, here is an idea at how to 
getting a release out ASAP and make Action easier to manage:

- Put all subprojects under Action 1
- Merge Faces into Extras
- Merge EL into taglibs
- Get strict with tickets - only let bugs hold us up, and then, only 
ones we agree should hold us back.  Most projects ship with bugs, just 
we'd make sure to document them.


Bottom line, the fewer subprojects and even "modules", the quicker a GA 
release will happen and the easier the project will be to manage.  We 
are _way_ overdue on this release and I'm now hearing some literally 
don't think it will _ever_ be finished, and worse, that we don't care.


Don

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