Re: [WebWork2] TODO

[Rainer Hermanns]

Hey there,

I share Alex' opinion on DOJO. We should not add to many dependencies for
"core" components into the themes for now.
DOJO is still quite unstable and we should wait until their basis gets a
bit more stable.

Regarding the other AJAX themes, there were plans already to rename the
current "ajax" theme to "dojo" and provide a new theme "prototype" based
on prototype and script.aculo.us.
A third ajax enabled theme was discussed to include the Yahoo components.

But these developments are still in progress or on hold til now, cause
of the webwork 2.2.2 release.

cheers,
Rainer

> pls see inlined
>
> On 3/27/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>>
>> STATUS update
>> 
>>
>> DISTRIBUTION RIGHTS - LICENSING
>>
>> JSCalendar for the DatePicker tag
>> * Rene will contact author about license change
>> * There may also be a Dojo equivalent
>>
>> FCKEditor for the Richtexteditor tag
>> * Is there a Dojo equivalent?
>>
>> Walter Zorns tooltip library for all UI Tags
>> * Is there a Dojo equivalent?
>
>
> I had very bad experiences with Dojo so far, and I brought this into
> discussion on ww forums. I wouldn't encourage moving to Dojo, because the
> browser support is still lacking, and from the feeling we got from their
> ml
> some of the old browsers, that are still used (f.e. IE 5.5) will be
> missing
> in the next versions.
>
> hth,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> [trimmed rest of original mail]
>


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

Re: [WebWork2] Status

[Rainer Hermanns]

Good job, Frank!
To enhance these pages with "webworkish/action2" best practices, is there
a page with common best practices for Struts 1.x that we should document
in a webwork/action2 way?

This might people get started with Action 2 more easily if there is a
direct comparision possible.

cheers,
Rainer

> Frank, good job!  I like the discussion on the missing ForwardAction as
> that is something Struts users would immediately pick up.  IIRC, Ted
> noticed that as well and started a dialog about it on the WW forum.  I
> look forward to more good tips and discussion. :)
>
> Don
>
> Frank W. Zammetti wrote:
>> Did a little reorganizing of that page, added a little verbiage to
>> describe some things, and put in two "starter" pages.  Hope everyone
>> likes it! (more importantly, because I'm certainly new to WW, I hope I
>> didn't get anything wrong!)
>>
>> Frank
>>
>> Don Brown wrote:
>>> Perfect!  Frank, you take the lead on that. You have a lot more
>>> experience in what works and doesn't with wiki pages, and are good at
>>> explaining topics at a user level - exactly what we need.  Those
>>> topics sound like a good start, yet flexible down the road.
>>>
>>> Let me know if there is anything I can do to help,
>>>
>>> Don
>>>
>>> Frank W. Zammetti wrote:
 Don, do you have a preference how you would like that Wiki page
 organized?  I've spent the last few days building (trying to anyway)
 a Webwork app, and I'd like to record one or two finds and thoughts.

 I was thinking a section under References named "Webwork From A
 Struts Perspective" with subsections "Migrating" (specifically
 dealing with migrating Struts apps to Webwork), "Issues and
 Solutions" (any issues a Struts developer might face in using
 Webwork for the first time, and how to solve them) and "General
 Thoughts" (things that maybe could be better, things that are a
 really nice and people should be aware of, etc.) might suffice.
 Each would just be a page of bullet points.  What do you think?

> Don

 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]
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

DO NOT REPLY [Bug 39139] New: - localozed float validator

[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=39139

   Summary: localozed float validator
   Product: Struts
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


When where is an international struts application, there is a need of 
localized validator.
For example: 
when user login with french locale, he types a float like 12,3; but current 
float validator returns false, because of ',' symbol.
Is there a plan to implement this feature soon?

Thanks.

-- 
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: r389756 - in /struts/site/trunk/xdocs: announce.xml mail.xml

[husted]

Author: husted
Date: Wed Mar 29 03:28:23 2006
New Revision: 389756

URL: http://svn.apache.org/viewcvs?rev=389756&view=rev
Log:
Announcements
 * Add Shale 1.0.2 Alpha
Mailing list 
 * Add "Don't Feed the Trolls" guideline 


Modified:
struts/site/trunk/xdocs/announce.xml
struts/site/trunk/xdocs/mail.xml

Modified: struts/site/trunk/xdocs/announce.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/announce.xml?rev=389756&r1=389755&r2=389756&view=diff
==
--- struts/site/trunk/xdocs/announce.xml (original)
+++ struts/site/trunk/xdocs/announce.xml Wed Mar 29 03:28:23 2006
@@ -26,6 +26,71 @@
 
 
 
+23 March 2006 - Struts Framework 1.0.2 
Alpha
+
+
+The Struts team is pleased to announce the release of Struts 
Shale 1.0.2 Alpha.
+
+
+
+
+http://struts.apache.org/downloads.html";>
+http://struts.apache.org/downloads.html
+
+
+
+The Struts Shale Framework is a set of loosely coupled 
services,
+fundamentally based on JavaServer Faces, which may be combined 
as
+needed to meet particular application requirements.
+
+
+Compared to version 1.0.0 (version 1.0.1 was retired due to 
packaging
+issues), this version includes a substantial number of 
bugfixes and
+enhancements -- details are in the Release Notes -- and the 
following
+major new features:
+
+
+
+
+Shale Remoting is a complete overhaul of the remoting 
support in
+1.0.0, providing support for application or component 
developers who
+need to implement the server side behavior for AJAX 
callbacks. It is
+packaged as a small (40k) JAR that has no dependencies on 
the rest of
+Shale.
+
+
+Tiger Extensions is an optional add-on layer for those 
running on
+Java SE 5 (code named "Tiger"). The extensions let you use 
Java
+annotations to declare managed beans or register JSF 
components,
+without needing entries in a faces-config.xml file.
+
+
+A new "blank" starter application to get you up and 
running with a
+new project quickly.
+
+
+A new "mailreader" demo application that duplicates the
+functionality of the Struts 1.x version of this app, so 
you can
+
+
+A new "SQL Browser" demo application that illustrates use 
of the
+Tiger Extensions, as well as the ability to modify JSF 
component trees
+on the fly.
+
+
+
+Although this is considered an alpha release, various 
developer APIs
+should be considered at a more stable (in terms of assurances 
of
+backwards compatibility in future releases) point than might 
otherwise
+be expected. Please see the following web page for more 
details:
+
+
+
+http://struts.apache.org/struts-shale/api-stability.html";>
+
http://struts.apache.org/struts-shale/api-stability.html
+
+
+
 22 March 2006 - Struts 1.2.9 (General
 Availability)
 

Modified: struts/site/trunk/xdocs/mail.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/mail.xml?rev=389756&r1=389755&r2=389756&view=diff
==
--- struts/site/trunk/xdocs/mail.xml (original)
+++ struts/site/trunk/xdocs/mail.xml Wed Mar 29 03:28:23 2006
@@ -191,7 +191,6 @@
 
 
 Watch where you are sending email.
-.
 The majority of our mailing lists have set the Reply-To to
 go back to the
 list. That means that when you Reply to a message, it will
@@ -217,6 +216,34 @@
 new and is considered off-topic.
 
 
+
+Don't feed the trolls.
+
+
+
+"In Internet terminology, a troll is a person who 
posts rude or offensive messages on the
+Internet, such as in online discussion forums, to 
disrupt discussion or to upset its
+participants (see Anonymous Internet posting). "Troll" 
can also

DO NOT REPLY [Bug 39141] New: - Shale tiger extension inside jboss, library path config

[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=39141

   Summary: Shale tiger extension inside jboss, library path config
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Inside JBOSS server the library location is not only WEB-INF/lib.
Maybe init parameter to change lib search location will be very good.

In the View annotation class , why you not asign the value of view id ?
and bean name for view ?
something like @View(viewId="/sec/test.jsp",name="sec$test") or more extended
@Views( [EMAIL PROTECTED](...),@View{...}} ? 

How can i change default maping ?


Cristi

-- 
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: r389760 - /struts/site/trunk/xdocs/mail.xml

[husted]

Author: husted
Date: Wed Mar 29 03:34:38 2006
New Revision: 389760

URL: http://svn.apache.org/viewcvs?rev=389760&view=rev
Log:
Mail 
* Add an anchor for each pointer 

Modified:
struts/site/trunk/xdocs/mail.xml

Modified: struts/site/trunk/xdocs/mail.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/mail.xml?rev=389760&r1=389759&r2=389760&view=diff
==
--- struts/site/trunk/xdocs/mail.xml (original)
+++ struts/site/trunk/xdocs/mail.xml Wed Mar 29 03:34:38 2006
@@ -52,7 +52,7 @@
 
 
 
-Respect the mailing list type
+Respect the mailing list type
 
 
 
@@ -107,7 +107,7 @@
 
 
 
-Ask smart questions.
+Ask smart questions.
 
 
 Every volunteer project obtains its strength from the
@@ -134,7 +134,7 @@
 
 
 
-Keep your email short and to the point.
+Keep your email short and to the 
point.
 
 
 If your email is more than about a page of text, chances
@@ -156,9 +156,8 @@
 
 
 
-Do your best to ensure that you are not sending HTML
-or
-"Stylelized" email to the list.
+Do your best to ensure that you are 
not sending HTML
+or "Stylelized" email to the list.
 
 
 If you are using Outlook or Outlook Express or Eudora,
@@ -177,7 +176,7 @@
 
 
 
-Do not cross post messages.
+Do not cross post messages.
 
 
 In other words, pick a mailing list and send your messages
@@ -190,7 +189,9 @@
 
 
 
-Watch where you are sending email.
+
+Watch where you are sending 
email.
+
 The majority of our mailing lists have set the Reply-To to
 go back to the
 list. That means that when you Reply to a message, it will
@@ -217,7 +218,9 @@
 
 
 
-Don't feed the trolls.
+
+Don't feed the trolls.
+
 
 
 
@@ -226,11 +229,11 @@
 participants (see Anonymous Internet posting). "Troll" 
can also mean the message itself or be a
 verb meaning to post such messages. "Trolling" is also 
commonly used to describe the activity."
 
-
-For more, see
-http://en.wikipedia.org/wiki/Internet_trolls";>Internet Trolls
-in the Wikipedia.
-
+
+For more, see
+http://en.wikipedia.org/wiki/Internet_trolls";>Internet Trolls
+in the Wikipedia.
+
 
 
 If someone makes an off-topic post that offends you,



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

DO NOT REPLY [Bug 38487] - [Tiger] Heap memory error when a lot of jars in WEB-INF/lib

[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=38487





--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 12:42 ---


About WEB-INF/lib, and file to find faces-config.xml , maybe you can configure
this some way. Some regular expression is a good ideea.

In case of a big aplication server like jboss, the class path is not always so
simple. 


Cristi


-- 
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: r389767 - /struts/site/trunk/xdocs/announce.xml

[husted]

Author: husted
Date: Wed Mar 29 03:48:32 2006
New Revision: 389767

URL: http://svn.apache.org/viewcvs?rev=389767&view=rev
Log:
Announcements
* Correct typo.

Modified:
struts/site/trunk/xdocs/announce.xml

Modified: struts/site/trunk/xdocs/announce.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/announce.xml?rev=389767&r1=389766&r2=389767&view=diff
==
--- struts/site/trunk/xdocs/announce.xml (original)
+++ struts/site/trunk/xdocs/announce.xml Wed Mar 29 03:48:32 2006
@@ -26,7 +26,7 @@
 
 
 
-23 March 2006 - Struts Framework 1.0.2 
Alpha
+23 March 2006 - Struts Shale Framework 1.0.2 
Alpha
 
 
 The Struts team is pleased to announce the release of Struts 
Shale 1.0.2 Alpha.



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

svn commit: r389779 - /struts/site/trunk/xdocs/mail.xml

[husted]

Author: husted
Date: Wed Mar 29 04:17:50 2006
New Revision: 389779

URL: http://svn.apache.org/viewcvs?rev=389779&view=rev
Log:
Mailing Lists 
* Add link to QuickTopic 

Modified:
struts/site/trunk/xdocs/mail.xml

Modified: struts/site/trunk/xdocs/mail.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/mail.xml?rev=389779&r1=389778&r2=389779&view=diff
==
--- struts/site/trunk/xdocs/mail.xml (original)
+++ struts/site/trunk/xdocs/mail.xml Wed Mar 29 04:17:50 2006
@@ -104,7 +104,14 @@
 questions
 there.
 
-
+
+If you would like to discuss a topic outside the usual 
scope of our mailing lists,
+please create a
+http://quicktopic.com/";>
+QuickTopic
+
+and invite others to join the conversation.
+
 
 
 Ask smart questions.
@@ -125,8 +132,8 @@
 http://www.catb.org/~esr/faqs/smart-questions.html";>
 "
-Asking
-Smart Questions
+Asking
+Smart Questions
 "
 
 precisely on this topic.



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

svn commit: r389786 - /incubator/webwork2/STATUS.txt

[husted]

Author: husted
Date: Wed Mar 29 04:57:39 2006
New Revision: 389786

URL: http://svn.apache.org/viewcvs?rev=389786&view=rev
Log:
Update to jive with comments on list.

Modified:
incubator/webwork2/STATUS.txt

Modified: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=389786&r1=389785&r2=389786&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Wed Mar 29 04:57:39 2006
@@ -10,8 +10,15 @@
 
 As items are resolved here, they should be removed and noted on the formal 
checklist.
 
-
+Other resources: 
+
+* Webwork2/Action2 incubator repository - 
http://svn.apache.org/viewcvs.cgi/incubator/webwork2/
+
+* StrutsAction2 wiki area - http://wiki.apache.org/struts/StrutsAction2
 
+* New Action2 sandbox code - 
https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/
+
+
 
 DISTRIBUTION RIGHTS - LICENSING
 
@@ -48,6 +55,46 @@
 
 +1 Gabe
 
+MIGRATING FROM ACTION 1 TO ACTION 2 
+
+An area on the wiki is devoted to migrating from Action 1 to Action 2 
+
+* http://wiki.apache.org/struts/StrutsAction2
+
+There is an Apps area in the sandbox for new Action2 code, starting with 
+example applications.
+
+* https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/
+
+** The MailReader application has been ported. Comments and fixes 
+welcome. The "Tour" is next.
+
+** A new Cookbook application has been started. The suggestion is 
+that we combine the WW Showcase examples and the various Struts 
+Examples into a unified cookbook. The cookbook application can 
+display the code used to create the "recipes", like the Tomcat 
+Example application.
+
+** The design of the cookbook makes it easy to add new recipes. 
+Please feel free to jump in and contribute!
+
 
+
+WORKING ACTION2 BUILD 
+
+* The WebWork2 Incubator code now builds struts-action-2.0-dev.jar
+
+** This JAR can be placed into your sandboxes for runtime testing
+
+* The initial renaming is complete,and the repository seems stable 
+enough to make further changes.  
+
+* The WebWork 2 project had a continuous integration server for automated
+builds and testing.It would be valuable to have that service, even while 
+in the Incubator. 
+
+** What about setting up a temporary build server either in an 
+Apache zone or on a developer's computer?
+
 
 



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

Re: [WebWork2] Status

[Ted Husted]

On 3/28/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I don't know about a weekly message, but I'll try to get something out 
> somewhere close to that.  Keep up the good work!

I updated the STATUS file to include the new items mentioned here.

> [1] http://svn.apache.org/viewcvs.cgi/incubator/webwork2/STATUS.txt

The ancient tradition is to post the STATUS file to dev@ on a weekly
or monthly basis.

-Ted.

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

Re: [WebWork2] Status

[Ted Husted]

On 3/29/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> Good job, Frank!
> To enhance these pages with "webworkish/action2" best practices, is there
> a page with common best practices for Struts 1.x that we should document
> in a webwork/action2 way?

There's the original Struts Catalog

* http://husted.com/struts/catalog.html

as well as the wiki version

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

And I  did a presentation last year on "Action 1" practices, both good
and best.

* 
http://opensource.atlassian.com/confluence/oss/pages/viewpageattachments.action?pageId=829

-Ted.

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

[Struts Wiki] Update of "IssuesAndSolutions" by TedHusted

[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 TedHusted:
http://wiki.apache.org/struts/IssuesAndSolutions

The comment on the change is:
Add two from my list. I think the ForwardAction issue is obsolete. 

--
  This page is meant to be a list of issues that users ave encountered while 
migrations existing Struts Action 1.x application to Webwork, or developing new 
Webwork-based applications.  If you have a solution to the issue that will of 
course be most helpful, but even if you don't it is worth noting what you 
encountered none the less in the hopes that someone else can come along and 
answer it for you, and the rest of us.
  
+  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
  
   Webwork does not have an analogy to them Struts !ForwardAction. 
  One of the Struts "best practices" is that all requests within an application 
should go through Struts.  So, you should generally never reference a JSP 
directly for instance.  To help with this, Struts provides the !ForwardAction, 
which is more or less an Action that does nothing, it just immediately returns 
and forwards to the URI as configured.  Webwork does not appear to have a 
direct analogy to this.  However, it is easy to get the same effect in a couple 
of possible ways.

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

[Struts Wiki] Update of "IssuesAndSolutions" by TedHusted

[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 TedHusted:
http://wiki.apache.org/struts/IssuesAndSolutions

The comment on the change is:
Add link to forum thread

--
   How to set the focus on a form field? 
  ** http://forums.opensymphony.com/thread.jspa?threadID=23777&tstart=0
  
-  Webwork does not have an analogy to them Struts !ForwardAction. 
+  What is the analogy to ForwardAction? 
+ 
+ http://forums.opensymphony.com/thread.jspa?messageID=46135됷
+ 
+ 
+ 
  One of the Struts "best practices" is that all requests within an application 
should go through Struts.  So, you should generally never reference a JSP 
directly for instance.  To help with this, Struts provides the !ForwardAction, 
which is more or less an Action that does nothing, it just immediately returns 
and forwards to the URI as configured.  Webwork does not appear to have a 
direct analogy to this.  However, it is easy to get the same effect in a couple 
of possible ways.
  
  First, you can write a simple Action like so:

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

Re: [WebWork2] Status

[Ted Husted]

On 3/29/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> OTOH, as Ted pointed out, the ActionSupport class already does this by
> default, so in fact there probably is no need for a new class (just
> updated the Wiki to reflect this... I think I missed this originally in
> that thread).

I added two other recent issues to the page, with links to the forum
thread, along with a link to the ForwardAction thread in the forum.

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

-Ted.

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

Re: [Standalone Tiles] Maybe too much bound to Locale

[Antonio Petrelli]

Greg Reddin ha scritto:


But what about adding an API that requires a generic Object key 
parameter to support the 3rd dimension?




That would be fine! But to support also the 4th, the 5th... ;-)


Well, it can get pretty crazy.  I think we should *at most* provide 
support for the 3rd with an extensible object.  If someone wants the 
object to provide support for multiple dimensions then that's their 
prerogative.


I really was joking :-P In fact I use an object with that express 
(normally) two dimensions. So you have a line of choice (without locale) 
or a plane (with locale); gee! this geometry thing was useful then! :-P
I wonder how hard it would be for you to extend DefinitionsFactory 
with a KeyedDefinitionsFactory that provided the same method.




Uh you're right, I did not see it from this point of view, so I am 
definitely going to implement outside of Tiles core. But that's still a 
problem. I suppose that I need to extend TilesUtil, especially implement 
TilesUtil.getDefinition, then maybe I need to override TilesServlet to 
put my own implementation of TilesUtil. Then I should call 
TilesUtil.setTilesUtil...
Err... sorry that's something I don't like. You are going to refactor 
TilesUtil, aren't you? Using a class with static methods all over the 
application is (IMHO) poor design... But maybe you are going to refactor 
it so it is a false problem ;-)


Ciao
Antonio

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

[Struts Wiki] Update of "Panchasheel" by Panchasheel

[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 Panchasheel:
http://wiki.apache.org/struts/Panchasheel

New page:
##language:en
== Your Name ==

Email: [[MailTo(you AT SPAMFREE example DOT com)]]

...


CategoryHomepage

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

svn commit: r389820 - in /struts/sandbox/trunk/action2: README.txt apps/mailreader/src/java/mailreader2/ApplicationListener.java apps/mailreader/src/webapp/WEB-INF/web.xml

[husted]

Author: husted
Date: Wed Mar 29 08:18:48 2006
New Revision: 389820

URL: http://svn.apache.org/viewcvs?rev=389820&view=rev
Log:
Action2 Apps
* Mailreader Tour - Work in Progress
** Up to "Welcome.do" 

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

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/ApplicationListener.java
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/ApplicationListener.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/ApplicationListener.java?rev=389820&r1=389819&r2=389820&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/ApplicationListener.java
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/ApplicationListener.java
 Wed Mar 29 08:18:48 2006
@@ -50,6 +50,9 @@
  * Class to store protocol list (an array here). 
  * 
  * 
+ * 
+ * DEVELOPMENT NOTE - Another approach would be to instantiate the database 
via Spring.
+ * 
  */
 
 public final class ApplicationListener implements ServletContextListener {

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=389820&r1=389819&r2=389820&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml Wed 
Mar 29 08:18:48 2006
@@ -5,13 +5,13 @@
 Action2 Mailreader
 
 
-webwork
+action2
 
 com.opensymphony.webwork.dispatcher.FilterDispatcher
 
 
 
-webwork
+action2
 /*
 
 
@@ -28,17 +28,7 @@
 
 
 
-index.jsp
 index.html
 
 
-
-
 



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

[Struts Wiki] Update of "Panchasheel" by MichaelJouravlev

[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/Panchasheel

The comment on the change is:
Someone's experiments

--
+ deleted
- ##language:en
- == Your Name ==
  
- Email: [[MailTo(you AT SPAMFREE example DOT com)]]
- 
- ...
- 
- 
- CategoryHomepage
- 

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

[Struts Wiki] Update of "StrutsExtrasRelease131" by WendySmoak

[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 WendySmoak:
http://wiki.apache.org/struts/StrutsExtrasRelease131

The comment on the change is:
Next!

--
   
  == Release Manager ==
  
- The release manager is '''TBA'''
+ The release manager is '''Wendy Smoak'''
  
  == How to Help ==
  
@@ -42, +42 @@

  == Preparation Checklist ==
  
  || '''#''' || '''Description''' || '''Status''' ||
- || 1. || Announce plan to dev@ list; link from roadmap page || _ ||
+ || 1. || Announce plan to dev@ list or update Wiki page || (./) ||
  || 2. || Review/Resolve Outstanding Bugs || _ ||
  || 3. || Update Release Notes || _ ||
  || 4. || Check Dependencies || _ ||

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

[Struts Wiki] Trivial Update of "StrutsReleasePlans" by WendySmoak

[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 WendySmoak:
http://wiki.apache.org/struts/StrutsReleasePlans

--
  = 1. Struts Action 1.3.x Release Plans =
  
   *  StrutsClassicRelease130 - ''Struts Version 1.3.0''
-  *  StrutsActionRelease131 - ''Struts Action Version 1.3.1'' (pending)
+  *  StrutsActionRelease131 - ''Struts Action Version 1.3.1'' 
   *  StrutsTaglibRelease131 - ''Struts Taglib Version 1.3.1'' (advanced 
planning)
-  *  StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (advanced 
planning)
+  *  StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (pending)
  
  = 2. Struts-Faces Release Plans =
  

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

svn commit: r389844 - /incubator/webwork2/ivy.xml

[mrdon]

Author: mrdon
Date: Wed Mar 29 09:51:15 2006
New Revision: 389844

URL: http://svn.apache.org/viewcvs?rev=389844&view=rev
Log:
Updating struts-action and apache info

Modified:
incubator/webwork2/ivy.xml

Modified: incubator/webwork2/ivy.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/ivy.xml?rev=389844&r1=389843&r2=389844&view=diff
==
--- incubator/webwork2/ivy.xml (original)
+++ incubator/webwork2/ivy.xml Wed Mar 29 09:51:15 2006
@@ -1,12 +1,12 @@
 
 http://www.jayasoft.fr/org/ivyrep/ivy-doc.xsl";?>
 
-
 http://www.apache.org/licenses/LICENSE-2.0.txt"/>
-http://www.opensymphony.com/"/>
+http://www.apache.org/"/>
 
 http://www.opensymphony.com/webwork/";>
 WebWork is a Java web-application development framework. It is 
built specifically with developer
@@ -44,7 +44,7 @@
 
 
 
-
+
 
 
 



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

DO NOT REPLY [Bug 34533] - Specify which module is causing an error in ModuleUtils.selectModule()

[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=34533





--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 18:52 ---
Should it maybe just do a return; in the else block (after removing)?

The code in the latest 1.2.x is the same, so there's no change from 1.2.4. 

So options seem to be:

1) Throw an Exception, because not having a ModuleConfig is bad.
2) Log an error, because not having a ModuleConfig is bad.
3) Add a return; (ie: null protect the later code); because not having an MC is 
fine, the code is just a bit 
sloppy.
4) Add a return; and log a warning; because not having an MC is probably not 
wanted.


-- 
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 34533] - Specify which module is causing an error in ModuleUtils.selectModule()

[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=34533





--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 18:55 ---
The following method:

 snip ...
 * @return the ModuleConfig object from request, or null if none is set in
 * the request.
 */
public ModuleConfig getModuleConfig(HttpServletRequest request) { ...

makes me think that a null config is fine, so the best thing would be to add a 
return before the block of 
code that NPEs.

-- 
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 39139] - localozed float validator

[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=39139





--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 19:48 ---
Looks like a Commons Validator issue (assuming you mean the Java validation 
rather than the JavaScript 
one).

I presume FieldChecks is the class that takes care of this in Struts, it points 
to formatFloat(String) in 
Validator's GenericTypeValidator. This calls new Float, which I'm pretty sure 
is not i18nised.

Instead the FieldChecks class should be doing Locale stuff for each number type 
and passing it in to 
methods of the type of formatFloat(String, Locale).

If this sounds good, I'll happily supply a patch.

-- 
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 39139] - localozed float validator

[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=39139


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 20:27 ---
This has already been addressed and fixed.

*** This bug has been marked as a duplicate of 21282 ***

-- 
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 21282] - [validator] numeric validations should use locales

[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=21282


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 20:27 ---
*** Bug 39139 has been marked as a duplicate of this bug. ***

-- 
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: r389877 - /struts/sandbox/trunk/action2/README.txt

[husted]

Author: husted
Date: Wed Mar 29 12:12:31 2006
New Revision: 389877

URL: http://svn.apache.org/viewcvs?rev=389877&view=rev
Log:
Action2 Apps
* Restore README.txt 


Added:
struts/sandbox/trunk/action2/README.txt
  - copied unchanged from r389644, struts/sandbox/trunk/action2/README.txt


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

Re: [WebWork2] Status

[Rainer Hermanns]

Ted,
thanks for the pointer... I will have a look at these soon...

Rainer

> On 3/29/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>> Good job, Frank!
>> To enhance these pages with "webworkish/action2" best practices, is
>> there
>> a page with common best practices for Struts 1.x that we should document
>> in a webwork/action2 way?
>
> There's the original Struts Catalog
>
> * http://husted.com/struts/catalog.html
>
> as well as the wiki version
>
> * http://wiki.apache.org/struts/StrutsCatalog
>
> And I  did a presentation last year on "Action 1" practices, both good
> and best.
>
> *
> http://opensource.atlassian.com/confluence/oss/pages/viewpageattachments.action?pageId=829
>
> -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]

JIRA instance

[Rainer Hermanns]

Hey there,

Just to keep the not-yet-apache webwork commiters up-to-date, is the  
Jira instance for Action2 already up and ready to use and are the 2.3  
scheduled issues already imported for Action2?
Any update on this would be helpful, cause lots of the current ww  
developers ask for this

If not, is there already a schedule for the migration?
If we are going to address open ww issues, how should those be  
addressed? Using the WW- syntax with the commit message?


cheers,
Rainer

Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:+49-241-4012247
m:  +49-170-3432912




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

Re: JIRA instance

[Don Brown]

Patrick is working with Jeff Turner to do the JIRA migration.  You can track 
the status by its infrastructure ticket [1].

As for working on the code, feel free to work on bugs and small fixes.  Let's hold off on major changes so that we can 
get an Action 2 release out ASAP.  Using the WW-### syntax is fine since we don't know exactly what the new one will be.


HTH,

Don


[1] http://issues.apache.org/jira/browse/INFRA-742

Rainer Hermanns wrote:

Hey there,

Just to keep the not-yet-apache webwork commiters up-to-date, is the 
Jira instance for Action2 already up and ready to use and are the 2.3 
scheduled issues already imported for Action2?
Any update on this would be helpful, cause lots of the current ww 
developers ask for this

If not, is there already a schedule for the migration?
If we are going to address open ww issues, how should those be 
addressed? Using the WW- syntax with the commit message?


cheers,
Rainer

Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:+49-241-4012247
m:  +49-170-3432912




-
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: r389881 - in /struts/sandbox/trunk/action2: PRACTICES.txt README.txt

[husted]

Author: husted
Date: Wed Mar 29 12:30:47 2006
New Revision: 389881

URL: http://svn.apache.org/viewcvs?rev=389881&view=rev
Log:
PRACTICES
* Add links to other resources
README 
* Update status of MailReader 

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

Modified: struts/sandbox/trunk/action2/PRACTICES.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/PRACTICES.txt?rev=389881&r1=389880&r2=389881&view=diff
==
--- struts/sandbox/trunk/action2/PRACTICES.txt (original)
+++ struts/sandbox/trunk/action2/PRACTICES.txt Wed Mar 29 12:30:47 2006
@@ -40,3 +40,18 @@
 
 * Centralize other application and business logic into a base class that 
action can share. 
 
+
+
+
+Other Best Practice Resources 
+
+* Showcase Best Practices thread - 
http://forums.opensymphony.com/thread.jspa?messageID=24691恳
+
+* Original "Action 1" Catalog - http://husted.com/struts/catalog.html
+
+* Wiki version - http://wiki.apache.org/struts/StrutsCatalog
+
+* "Action 1" Best Practices - 
http://opensource.atlassian.com/confluence/oss/pages/viewpageattachments.action?pageId=829
+
+
+

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=389881&r1=389880&r2=389881&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Wed Mar 29 12:30:47 2006
@@ -70,13 +70,14 @@
 ** 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?
 
 
 
 STATUS - MAILREADER
 
-* Work in progress.
+* Feature complete, but some marginal issue remain. 
+* Working on Tour
 
 
 
@@ -168,7 +169,7 @@
 
 
 Tour
-* TODO
+* In progress
 
 
 
@@ -187,6 +188,11 @@
 
 
 
+
+
+
+ApplicationListener
+* Another approach would be to instantiate the database via Spring.
 
 
 



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

Re: JIRA instance

[Rainer Hermanns]

Thanks Don,
I will tell this to all those OpenSymphony devs not yet following the  
Struts-dev list... (and of course telling them to follow this list)


cheers,
Rainer

On Mar 29, 2006, at 22:26 , Don Brown wrote:

Patrick is working with Jeff Turner to do the JIRA migration.  You  
can track the status by its infrastructure ticket [1].


As for working on the code, feel free to work on bugs and small  
fixes.  Let's hold off on major changes so that we can get an  
Action 2 release out ASAP.  Using the WW-### syntax is fine since  
we don't know exactly what the new one will be.


HTH,

Don


[1] http://issues.apache.org/jira/browse/INFRA-742

Rainer Hermanns wrote:

Hey there,
Just to keep the not-yet-apache webwork commiters up-to-date, is  
the Jira instance for Action2 already up and ready to use and are  
the 2.3 scheduled issues already imported for Action2?
Any update on this would be helpful, cause lots of the current ww  
developers ask for this

If not, is there already a schedule for the migration?
If we are going to address open ww issues, how should those be  
addressed? Using the WW- syntax with the commit message?

cheers,
Rainer
Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:+49-241-4012247
m:  +49-170-3432912
-
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]



Rainer Hermanns
aixcept
Neupforte 16
52062 Aachen - Germany
w: http://aixcept.de/
t:+49-241-4012247
m:  +49-170-3432912




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

Struts 1.3 and Internationalization

[Hermod Opstvedt]

Hi

What's the status of the Struts 1.3 branch with respect to
internationalization? In the 1.2 branch this was a "won't touch" issue. What
I am thinking about is amongst other things the ability to use comma as
decimal separator. Or is still "English only, please".

Also, and I know this is the wrong forum, does anybody know if validator
know supports "ALL" the struts specified resource bundles (including I18N).

Hermod


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

Re: Struts 1.3 and Internationalization

[Don Brown]

Struts, from the beginning has taken internationalization very seriously.  You are probably referring to the validation 
of numeric values.  This was a longstanding struts issue that has been resolved since Struts 1.2.7.  There are new 
validators that will serve your interests.


Don

Hermod Opstvedt wrote:

Hi

What's the status of the Struts 1.3 branch with respect to
internationalization? In the 1.2 branch this was a "won't touch" issue. What
I am thinking about is amongst other things the ability to use comma as
decimal separator. Or is still "English only, please".

Also, and I know this is the wrong forum, does anybody know if validator
know supports "ALL" the struts specified resource bundles (including I18N).

Hermod


-
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: JIRA instance

[Ted Husted]

On 3/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Patrick is working with Jeff Turner to do the JIRA migration.  You can track 
> the status by its infrastructure ticket [1].

> [1] http://issues.apache.org/jira/browse/INFRA-742

The ticket seems to say that "JIRA is ready to go".

If so, where is it? :)

-Ted.

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

SV: Struts 1.3 and Internationalization

[Hermod Opstvedt]

Hi

Not quite - If you have an html:text field, and enter a number with a comma
as decimal separator, and then try to access it in your action from the form
it will be null. Just go ahead and try it. As far as I remember, the "wont
touch" reasoning had to do with some code deep down in Struts not being able
to access the locale from the request, and adding support would mean no
backward compatibility. Correct me if I am wrong. It is quite some time
since I ran into this (1.2.2 or something), and I solved it by hacking the
html:text tag and some other places I do not remember.

Hermod


-Opprinnelig melding-
Fra: Don Brown [mailto:[EMAIL PROTECTED] 
Sendt: 29. mars 2006 22:50
Til: Struts Developers List
Emne: Re: Struts 1.3 and Internationalization

Struts, from the beginning has taken internationalization very seriously.
You are probably referring to the validation 
of numeric values.  This was a longstanding struts issue that has been
resolved since Struts 1.2.7.  There are new 
validators that will serve your interests.

Don

Hermod Opstvedt wrote:
> Hi
> 
> What's the status of the Struts 1.3 branch with respect to
> internationalization? In the 1.2 branch this was a "won't touch" issue.
What
> I am thinking about is amongst other things the ability to use comma as
> decimal separator. Or is still "English only, please".
> 
> Also, and I know this is the wrong forum, does anybody know if validator
> know supports "ALL" the struts specified resource bundles (including
I18N).
> 
> Hermod
> 
> 
> -
> 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 1.3 and Internationalization

[Hubert Rabago]

This is a BeanUtils issue.  It comes into play after you get your
ActionForm inside your Action.execute(), and you call
BeanUtils.copyProperties() to copy your form field's String value onto
your business object's field.

You can look at BeanUtils' converters and registering locale-aware ones.

Of course, for me, I use FormDef to handle formatted inputs like these.

This is a user-list topic and should probably move there.

Hubert

On 3/29/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote:
> Hi
>
> Not quite - If you have an html:text field, and enter a number with a comma
> as decimal separator, and then try to access it in your action from the form
> it will be null. Just go ahead and try it. As far as I remember, the "wont
> touch" reasoning had to do with some code deep down in Struts not being able
> to access the locale from the request, and adding support would mean no
> backward compatibility. Correct me if I am wrong. It is quite some time
> since I ran into this (1.2.2 or something), and I solved it by hacking the
> html:text tag and some other places I do not remember.
>
> Hermod
>
>
> -Opprinnelig melding-
> Fra: Don Brown [mailto:[EMAIL PROTECTED]
> Sendt: 29. mars 2006 22:50
> Til: Struts Developers List
> Emne: Re: Struts 1.3 and Internationalization
>
> Struts, from the beginning has taken internationalization very seriously.
> You are probably referring to the validation
> of numeric values.  This was a longstanding struts issue that has been
> resolved since Struts 1.2.7.  There are new
> validators that will serve your interests.
>
> Don
>
> Hermod Opstvedt wrote:
> > Hi
> >
> > What's the status of the Struts 1.3 branch with respect to
> > internationalization? In the 1.2 branch this was a "won't touch" issue.
> What
> > I am thinking about is amongst other things the ability to use comma as
> > decimal separator. Or is still "English only, please".
> >
> > Also, and I know this is the wrong forum, does anybody know if validator
> > know supports "ALL" the struts specified resource bundles (including
> I18N).
> >
> > Hermod
> >
> >
> > -
> > 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]
>
>

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

DO NOT REPLY [Bug 38000] - ShalePhaseListener executes ViewController.prerender twice after exception

[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=38000





--- Additional Comments From [EMAIL PROTECTED]  2006-03-29 22:51 ---
Created an attachment (id=18002)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18002&action=view)
another approach 

I was looking at the sequence of events that are fired on a postback or
invoking a command (button or link).

VewHandler.restoreView() --> ViewController.init();
ViewHandler.createView() --> ViewController.init();

The logic that tucks away the view controller for the phase listener is invoked
twice and two references to the view controller are added to the list.  This
patch checks to see if a reference exists before it's added.  This would happen
when the target navigation was back to the same page.

Since this is such a core part of Shale, I would like for some feedback before
going further.


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

SV: Struts 1.3 and Internationalization

[Hermod Opstvedt]

Hi

I know that that was one of the issues, and I use converters for this. OK,
maybe I will set up a test with the latest Struts and see If it is still an
issue, and if so file r.f.e

Hermod


-Opprinnelig melding-
Fra: Hubert Rabago [mailto:[EMAIL PROTECTED] 
Sendt: 29. mars 2006 23:40
Til: Struts Developers List; [EMAIL PROTECTED]
Emne: Re: Struts 1.3 and Internationalization

This is a BeanUtils issue.  It comes into play after you get your
ActionForm inside your Action.execute(), and you call
BeanUtils.copyProperties() to copy your form field's String value onto
your business object's field.

You can look at BeanUtils' converters and registering locale-aware ones.

Of course, for me, I use FormDef to handle formatted inputs like these.

This is a user-list topic and should probably move there.

Hubert

On 3/29/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote:
> Hi
>
> Not quite - If you have an html:text field, and enter a number with a
comma
> as decimal separator, and then try to access it in your action from the
form
> it will be null. Just go ahead and try it. As far as I remember, the "wont
> touch" reasoning had to do with some code deep down in Struts not being
able
> to access the locale from the request, and adding support would mean no
> backward compatibility. Correct me if I am wrong. It is quite some time
> since I ran into this (1.2.2 or something), and I solved it by hacking the
> html:text tag and some other places I do not remember.
>
> Hermod
>
>
> -Opprinnelig melding-
> Fra: Don Brown [mailto:[EMAIL PROTECTED]
> Sendt: 29. mars 2006 22:50
> Til: Struts Developers List
> Emne: Re: Struts 1.3 and Internationalization
>
> Struts, from the beginning has taken internationalization very seriously.
> You are probably referring to the validation
> of numeric values.  This was a longstanding struts issue that has been
> resolved since Struts 1.2.7.  There are new
> validators that will serve your interests.
>
> Don
>
> Hermod Opstvedt wrote:
> > Hi
> >
> > What's the status of the Struts 1.3 branch with respect to
> > internationalization? In the 1.2 branch this was a "won't touch" issue.
> What
> > I am thinking about is amongst other things the ability to use comma as
> > decimal separator. Or is still "English only, please".
> >
> > Also, and I know this is the wrong forum, does anybody know if validator
> > know supports "ALL" the struts specified resource bundles (including
> I18N).
> >
> > Hermod
> >
> >
> > -
> > 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]
>
>

-
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

[Joe Germuska]

At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:

This is a BeanUtils issue. ...

This is a user-list topic and should probably move there.


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't be pushed to a method 
which takes a locale as an argument, and this method amended to call 
that one with the system default locale.


Then, the few places where RequestUtils.populate is called could be 
refactored to pass in the session locale if it is available, then 
line 451 cited above could be changed to make a new instance of 
LocaleBeanUtilsBean with the current locale.  (I've never used the 
localized bean utils code, but I think this is basically how it is to 
be done...)


and that method is only called in three places, one of which passes 
along from an alternate signature in RequestUtils.  The other two 
places are in the base RequestProcessor and the PopulateActionForm 
command (which essentially obsoletes the RequestProcessor.)


One possible compatibility issue would be with how instances of 
LocaleBeanUtilsBean interact with statically registered converters -- 
if people have existing apps that register converters statically, I 
don't think that those would be picked up by a newly instantiated 
LocaleBeanUtilsBean -- which would bring up the deeper issue of 
registering converters for different situations, which may well be 
where things got mired down before?  I don't recall earlier 
discussion of the issue.


If nothing else, Hermod, could you check issues.apache.org for any 
possibly existing ticket, and if you don't find one, create one?  It 
would be better to have this discussion in the bug tracker so that it 
is archived in conjunction with the actual enhancement request.


Joe



At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:

Hi

Not quite - If you have an html:text field, and enter a number with a comma
as decimal separator, and then try to access it in your action from the form
it will be null. Just go ahead and try it. As far as I remember, the "wont
touch" reasoning had to do with some code deep down in Struts not being able
to access the locale from the request, and adding support would mean no
backward compatibility. Correct me if I am wrong. It is quite some time
since I ran into this (1.2.2 or something), and I solved it by hacking the
html:text tag and some other places I do not remember.



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

SV: SV: Struts 1.3 and Internationalization

[Hermod Opstvedt]

Hi

And now bells start ringing - It is starting to come back to me now, and
RequestUtils.populate was one of the places I hacked to solve my specific
problem back then (this is 2 years ago). I know that this was raised as an
issue not only by me, but also by others back then. I'll see if I can dig up
something from the archives

Hermod


-Opprinnelig melding-
Fra: Joe Germuska [mailto:[EMAIL PROTECTED] 
Sendt: 30. mars 2006 00:17
Til: Hermod Opstvedt; 'Struts Developers List'
Emne: Re: SV: Struts 1.3 and Internationalization

At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
>This is a BeanUtils issue. ...
>
>This is a user-list topic and should probably move there.

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/RequestUt
ils.html#341

The actual place where ActionForm properties are set:
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
ils.html#451

I see no reason why all this code couldn't be pushed to a method 
which takes a locale as an argument, and this method amended to call 
that one with the system default locale.

Then, the few places where RequestUtils.populate is called could be 
refactored to pass in the session locale if it is available, then 
line 451 cited above could be changed to make a new instance of 
LocaleBeanUtilsBean with the current locale.  (I've never used the 
localized bean utils code, but I think this is basically how it is to 
be done...)

and that method is only called in three places, one of which passes 
along from an alternate signature in RequestUtils.  The other two 
places are in the base RequestProcessor and the PopulateActionForm 
command (which essentially obsoletes the RequestProcessor.)

One possible compatibility issue would be with how instances of 
LocaleBeanUtilsBean interact with statically registered converters -- 
if people have existing apps that register converters statically, I 
don't think that those would be picked up by a newly instantiated 
LocaleBeanUtilsBean -- which would bring up the deeper issue of 
registering converters for different situations, which may well be 
where things got mired down before?  I don't recall earlier 
discussion of the issue.

If nothing else, Hermod, could you check issues.apache.org for any 
possibly existing ticket, and if you don't find one, create one?  It 
would be better to have this discussion in the bug tracker so that it 
is archived in conjunction with the actual enhancement request.

Joe



At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
>Hi
>
>Not quite - If you have an html:text field, and enter a number with a comma
>as decimal separator, and then try to access it in your action from the
form
>it will be null. Just go ahead and try it. As far as I remember, the "wont
>touch" reasoning had to do with some code deep down in Struts not being
able
>to access the locale from the request, and adding support would mean no
>backward compatibility. Correct me if I am wrong. It is quite some time
>since I ran into this (1.2.2 or something), and I solved it by hacking the
>html:text tag and some other places I do not remember.


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


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

Re: SV: Struts 1.3 and Internationalization

[Hubert Rabago]

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't be pushed to a method
> which takes a locale as an argument, and this method amended to call
> that one with the system default locale.

I would agree if we weren't recommending that people use Strings in
the ActionForm [1].

What I'm saying is that your form should have String values and
RequestUtils.populate() will populate it whatever your user typed in,
and then in your Action you can use BeanUtils or FormDef to properly
parse that into your business object typed field.

You can see this in action in the locale.war demo of FormDef [2].

> Joe

Hubert

[1] "... properties used with the html:text tag should still be String
properties." 
http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
[2] http://www.rabago.net/struts/formdef/downloads.htm

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

Re: SV: Struts 1.3 and Internationalization

[Martin Cooper]

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't be pushed to a method
> > which takes a locale as an argument, and this method amended to call
> > that one with the system default locale.
>
> I would agree if we weren't recommending that people use Strings in
> the ActionForm [1].


Exactly. The "best practice" ever since Struts was created has been to use
strings for form fields, specifically so that you have the exact original
value to present to the user in an error situation. Once you bring other
data types into the picture, you can no longer guarantee that you can
redisplay exactly what the user (mis-)typed.

--
Martin Cooper


What I'm saying is that your form should have String values and
> RequestUtils.populate() will populate it whatever your user typed in,
> and then in your Action you can use BeanUtils or FormDef to properly
> parse that into your business object typed field.
>
> You can see this in action in the locale.war demo of FormDef [2].
>
> > Joe
>
> Hubert
>
> [1] "... properties used with the html:text tag should still be String
> properties."
> http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> [2] http://www.rabago.net/struts/formdef/downloads.htm
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: JIRA instance

[Martin Cooper]

On 3/29/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 3/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > Patrick is working with Jeff Turner to do the JIRA migration.  You can
> track the status by its infrastructure ticket [1].
>
> > [1] http://issues.apache.org/jira/browse/INFRA-742
>
> The ticket seems to say that "JIRA is ready to go".
>
> If so, where is it? :)


Gone? ;-)

--
Martin Cooper


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

Re: SV: SV: Struts 1.3 and Internationalization

[Paul Benedict]

I thought Commons Validator contained a locale attribute
so that certain validations could apply accordingly.
Wouldn't this help him out?

--- Hermod Opstvedt <[EMAIL PROTECTED]> wrote:

> Hi
> 
> And now bells start ringing - It is starting to come back to me now, and
> RequestUtils.populate was one of the places I hacked to solve my specific
> problem back then (this is 2 years ago). I know that this was raised as an
> issue not only by me, but also by others back then. I'll see if I can dig up
> something from the archives
> 
> Hermod
> 
> 
> -Opprinnelig melding-
> Fra: Joe Germuska [mailto:[EMAIL PROTECTED] 
> Sendt: 30. mars 2006 00:17
> Til: Hermod Opstvedt; 'Struts Developers List'
> Emne: Re: SV: Struts 1.3 and Internationalization
> 
> At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
> >This is a BeanUtils issue. ...
> >
> >This is a user-list topic and should probably move there.
> 
> 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/RequestUt
> ils.html#341
> 
> The actual place where ActionForm properties are set:
> http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUt
> ils.html#451
> 
> I see no reason why all this code couldn't be pushed to a method 
> which takes a locale as an argument, and this method amended to call 
> that one with the system default locale.
> 
> Then, the few places where RequestUtils.populate is called could be 
> refactored to pass in the session locale if it is available, then 
> line 451 cited above could be changed to make a new instance of 
> LocaleBeanUtilsBean with the current locale.  (I've never used the 
> localized bean utils code, but I think this is basically how it is to 
> be done...)
> 
> and that method is only called in three places, one of which passes 
> along from an alternate signature in RequestUtils.  The other two 
> places are in the base RequestProcessor and the PopulateActionForm 
> command (which essentially obsoletes the RequestProcessor.)
> 
> One possible compatibility issue would be with how instances of 
> LocaleBeanUtilsBean interact with statically registered converters -- 
> if people have existing apps that register converters statically, I 
> don't think that those would be picked up by a newly instantiated 
> LocaleBeanUtilsBean -- which would bring up the deeper issue of 
> registering converters for different situations, which may well be 
> where things got mired down before?  I don't recall earlier 
> discussion of the issue.
> 
> If nothing else, Hermod, could you check issues.apache.org for any 
> possibly existing ticket, and if you don't find one, create one?  It 
> would be better to have this discussion in the bug tracker so that it 
> is archived in conjunction with the actual enhancement request.
> 
> Joe
> 
> 
> 
> At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
> >Hi
> >
> >Not quite - If you have an html:text field, and enter a number with a comma
> >as decimal separator, and then try to access it in your action from the
> form
> >it will be null. Just go ahead and try it. As far as I remember, the "wont
> >touch" reasoning had to do with some code deep down in Struts not being
> able
> >to access the locale from the request, and adding support would mean no
> >backward compatibility. Correct me if I am wrong. It is quite some time
> >since I ran into this (1.2.2 or something), and I solved it by hacking the
> >html:text tag and some other places I do not remember.
> 
> 
> -- 
> 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]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [VOTE] Struts Shale v1.0.2 Quality

[Sean Schofield]

Alpha and beta releases on ibiblio (for maven purposes) works for me. 
Final releases on the ASF mirror network.

Sean

On 3/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 3/27/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >
> > On 3/26/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> > > It was implicitly evident on the dev list, but not announced on the user
> > > list because that was my understanding of non-GA releases at the time.
> > > Subsequently, I believe we determined that we'd announce the vote
> > results
> > > for any quality level on the user list too.  That's what I'd like to
> > see,
> > > unless one of the other committers thinks I'm not remembering things
> > > correctly.
> > ...
> > > +1 ... and the MyFaces lists would probably make a reasonable cc on the
> > > announcement mail, since they are JSF -interested folks.
> > >
> > > We also need to update the web site to have appropriate links ... can
> > you do
> > > that too, please?
> >
> > After some consideration, I decided to update
> > http://struts.apache.org/downloads.html
> > to link to http://cvs.apache.org/dist/struts/shale/v1.0.2/ .
> >
> > That seems to fit with the docs here:
> > http://www.apache.org/dev/mirrors.html in that an Alpha release is
> > 'not ready for prime time.'
>
>
>
> Any other interpretations?
>
>
> +1 ... it should definitely not go out on the mirrors network until we do a
> GA release.
>
> --
> > Wendy
>
>
> Craig
>
>

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

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

[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 00:41 ---
(In reply to comment #6)
> I started into some of this on Saturday, but then ran out of time.  I have a
> path which I think will work out; it involves using a commons chain to string
> together configuration steps, more or less one for each "init" method in
> ActionServlet.  At the end, it would set something into application scope so
> that ActionServlet could be changed to look for that and skip configuration 
> when
> it was present.
> 
> It will be a fair bit of work to finish all of this, so I'd kind of like to 
> get
> a bit of feedback before I slog through it all (including whether anyone 
> besides
> Niall thinks its worthwhile!).

This sounds great.  Perhaps an optional command could be included in the
initialization chain to allow Struts developers to provide their own one-time
initialization logic.  For example, registration of custom commons-beanutils
Converters for application-specific object types.

-- 
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: JIRA instance

[Don Brown]

We now have a fully functioning JIRA instance: http://issues.apache.org/struts

Thanks to Jeff Turner and Patrick Lightbody for making the migration a success!  The WebWork tickets have been migrated, 
and you'll note, we get our own JIRA instance.  The plan is to now migrate Struts Action and Shale Bugzilla tickets into 
it.  The WebWork project will be named such until it graduates from the Incubator.


So far, I've found Joe and Ted, and made them admins too.  I'd imagine the 
guidelines would go:
 - Struts PMC members get JIRA Admin
 - Struts Committers get project developer

Register and let one of us know, so we can give you the appropriate permissions.

Don

Martin Cooper wrote:

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

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

Patrick is working with Jeff Turner to do the JIRA migration.  You can

track the status by its infrastructure ticket [1].


[1] http://issues.apache.org/jira/browse/INFRA-742

The ticket seems to say that "JIRA is ready to go".

If so, where is it? :)



Gone? ;-)

--
Martin Cooper


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

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

[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 00:47 ---
(In reply to comment #8)
> Perhaps an optional command could be included in the
> initialization chain to allow Struts developers to provide their own one-time
> initialization logic.  

Struts plugins already provide this functionality.  In containers that support 
them, ServletContextListeners are another option [1].

Hubert

[1] http://marc.theaimsgroup.com/?l=struts-user&m=110840823606930&w=2


-- 
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 39148] New: - [controller] Support commons-chain Command as Controller

[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=39148

   Summary: [controller] Support commons-chain Command as Controller
   Product: Struts
   Version: Unknown
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Tiles
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Please add support for commons-chain Command as the Controller for a Tile.

For example, add CommandController class as a peer of ActionController and
UrlController.

Please also add XML syntax to configure the commons-chain Command in the Tile
definition.

For example, add controllerCatalog and controllerCommand attributes to
 element in Tiles configuration.

Perhaps it would be worth also creating a TilesContext (similar to ActionContext
in struts-action project) that provides strongly typed access to objects needed
during Tiles Controller execution.

-- 
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: r389951 - in /struts/sandbox/trunk/action2: ./ apps/mailreader/src/java/ apps/mailreader/src/java/mailreader2/ apps/mailreader/src/webapp/pages/

[husted]

Author: husted
Date: Wed Mar 29 17:15:06 2006
New Revision: 389951

URL: http://svn.apache.org/viewcvs?rev=389951&view=rev
Log:
Action2 Apps
* Mailreader
** Add an Interceptor to verify resources 

Added:

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java
   (with props)
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/xwork.xml
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Error.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=389951&r1=389950&r2=389951&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Wed Mar 29 17:15:06 2006
@@ -195,4 +195,9 @@
 * Another approach would be to instantiate the database via Spring.
 
 
+
+
+VerifyResourcesInterceptor
+* Could use a better test to detect whether message resources loaded
+
 

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=389951&r1=389950&r2=389951&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
 Wed Mar 29 17:15:06 2006
@@ -80,6 +80,31 @@
  */
 public static final String USER_KEY = "user";
 
+//  Error Messages 
+
+/**
+ * 
+ * A static message in case message resource is not loaded.
+ * 
+ */
+public static final String ERROR_MESSAGES_NOT_LOADED =
+"ERROR:  Message resources not loaded -- check servlet container 
logs for error messages.";
+
+/**
+ * 
+ * A static message in case database resource is not loaded.
+ * 
+ */
+public static final String ERROR_DATABASE_NOT_LOADED =
+"ERROR:  User database not loaded -- check servlet container logs 
for error messages.";
+
+/**
+ * 
+ * A standard key from the message resources file, to test if it is 
available.
+ * 
+ */
+public static final String ERRORS_REQUIRED = "errors.required";
+
 //  Log Messages 
 
 /**

Added: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java?rev=389951&view=auto
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java
 (added)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java
 Wed Mar 29 17:15:06 2006
@@ -0,0 +1,70 @@
+package mailreader2;
+
+import com.opensymphony.xwork.interceptor.Interceptor;
+import com.opensymphony.xwork.*;
+
+import java.util.Map;
+
+import org.apache.struts.apps.mailreader.dao.UserDatabase;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+public class VerifyResourcesInterceptor implements Interceptor  {
+
+protected static final Log log = 
LogFactory.getLog(VerifyResourcesInterceptor.class);
+
+public void destroy () {}
+
+public void init() {}
+
+private void addError(ValidationAware validation, String message) {
+if (validation != null) {
+validation.addActionError(message);
+}
+log.error(message);
+}
+
+public String intercept(ActionInvocation invocation) throws Exception {
+
+int errors = 0;
+
+Map application = invocation.getInvocationContext().getApplication();
+
+ValidationAware validation = null;
+
+final Object action = invocation.getAction();
+if (action instanceof ValidationAware) {
+validation = (ValidationAware) action;
+}
+
+// Confirm message resources loaded
+if (action instanceof TextProvider) {
+TextProvider tp = (TextProvider) action;
+String message = tp.getText(Constants.ERRORS_REQUIRED);
+if (null==message) {
+addError(validation,Constants.ERROR_MESSAGES_NOT_LOADED);
+errors++;
+}
+}
+
+// Confirm database loaded
+UserDatabase database = (UserDatabase) 
application.get(Constants.DATABASE_KEY);
+if (null==database) {
+  try {
+  
validation.a

Re: [Struts Ti] XWork?

[Gabe]

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

Important note: this does not mean merging Webwork and XWork, just making them 
two subsections of Struts Action 2.0.

Other important notes: The functionality of Struts 1.* is equivalent to XWork + 
Webwork not just Webwork, and without XWork SAF 2 would be an action framework 
without an action class.

Making that decision is very important in determining other things as they come 
up. The recent example is package naming. If we put Webwork code at 
some.struts.action2.root package, then where would XWork go? I strongly suspect 
there will be other decisions made that will similarly be better done if we 
know whether XWork would be a part of Struts Action 2.0.

Recent events support the Struts Action 2.0 = Webwork + XWork argument. There 
was the question of whether a ForwardAction should be created or how it related 
to XWORK's ActionSupport. I suspect that a lot of these questiosn of how Struts 
Classic compares to XWork will need to be asked in the future not only by 
struts developers but also by those interested in moving from Struts Classic to 
Struts Action 2.0. We will get tons of questions about how Actions / 
configuration compare from Struts Classic to XWork's, want to provide migration 
strategies from struts-configs to xwork-configs from struts ActionSupport to 
xwork ActionSupport.

This means that advantages of moving XWork at the same time as Webwork are:
1) one users list to deal with user comments on both Action issues (XWork) and 
Tag/view issues (Webwork)
2) The ability to coordinate releases or add features (For example the 
ForwardAction) that will help Struts Classic users migrate to Action 2. 
(Currently, it should be noted, XWork and Webwork releases happen pretty much 
simultaneously with an XWork version coming out and then a Webwork.)
3) The ability for documentation for Action 2 to more gracefully contain 
integrated documentation on its action structure.

I think going forward, if you are opposed to bringing XWork in immediately, 
then the following questions should be answered:
1) How would XWork questions be answered? Would the struts list serve as a 
second xwork mailing list or would questions be forwarded to opensymphony?
2) Would large amounts of struts documentation serve to duplicate XWork 
documentation or would struts developers be forwarded to xwork documentation?

It is important to decide those issues, because for a new 'revolutionary' 
approach, we wouldn't want to switch midstream how users approach XWork classes 
(start out with open symphony ActionSupport and then have to move to a struts 
one for example), since they are so integral to the app. 

I hope this clarifies why I think this is a decision we should make now.

Gabe














- Original Message 
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Saturday, March 25, 2006 5:22:47 PM
Subject: Re: [Struts Ti] XWork?

On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
> I'm sure I could come up with more reasons, but this is a good start to this 
> discussion.

I don't think anyone would have a problem with this, Gabe. It's just a
matter of whether we need to bring XWork and WebWork through
simultaneously, or whether we can do them one and then the other. (If
that's what the XWork developers would like.)

As I understand it, XWork is being used in applications other than
WebWork. If XWork had a stronger self-identify, other applications
might find it helpful too.

- (also from a different message by Ted)

As to the package naming, did anyone want to change their vote to
followup on Gabe's suggestion? Otherwise, it looks like the
conventions suggested by Rainer have the most support.

I don't know if we want to bring XWork into the ASF now, later, or
never. Of course, it's a great package and I'm sure we'd love to have
it, if the XWork developers would like to donate and support it.

There would also be the question of whether XWork is something that we
would maintain here, or whether we might want to propose it to the
Jakarta Commons, where it might find a broader audience.

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

svn commit: r389964 - in /struts/sandbox/trunk/action2/apps/mailreader/src: java/mailreader2/MailreaderSupport.java java/mailreader2/VerifyResourcesInterceptor.java java/mailreader2/Welcome.java java/

[husted]

Author: husted
Date: Wed Mar 29 18:08:10 2006
New Revision: 389964

URL: http://svn.apache.org/viewcvs?rev=389964&view=rev
Log:
Action2 Apps
* Mailreader
** Change to an action to verify resources

Added:

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java  
 (with props)
Removed:

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/VerifyResourcesInterceptor.java
Modified:

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/WEB-INF/web.xml
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html

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=389964&r1=389963&r2=389964&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
 Wed Mar 29 18:08:10 2006
@@ -263,7 +263,7 @@
 public UserDatabase getDatabase() {
 Object db = getApplication().get(Constants.DATABASE_KEY);
 if (db == null) {
-this.addActionError("error.database.missing");
+this.addActionError(getText("error.database.missing"));
 }
 return (UserDatabase) db;
 }

Added: 
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=389964&view=auto
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java 
(added)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java 
Wed Mar 29 18:08:10 2006
@@ -0,0 +1,33 @@
+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.
+ */
+public class Welcome extends MailreaderSupport {
+
+public String execute() throws Exception {
+
+// Confirm message resources loaded
+String message = getText(Constants.ERRORS_REQUIRED);
+if (Constants.ERRORS_REQUIRED.equals(message)) {
+addActionError(Constants.ERROR_MESSAGES_NOT_LOADED);
+}
+
+// Confirm database loaded
+UserDatabase database = getDatabase();
+if (null==database) {
+ addActionError(Constants.ERROR_DATABASE_NOT_LOADED);
+}
+
+if (hasErrors()) {
+return Action.ERROR;
+}
+else {
+return ActionSupport.SUCCESS;
+}
+}
+}

Propchange: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Welcome.java
--
svn:eol-style = native

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=389964&r1=389963&r2=389964&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml (original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml Wed Mar 29 
18:08:10 2006
@@ -8,7 +8,6 @@
 
 
 
-
 
 
 
@@ -20,16 +19,11 @@
 
 
 
-
-
-
-
-
 
 
 
 
-
+
 
 
 /pages/Error.jsp
@@ -45,14 +39,8 @@
 
 
 
-
-
-
+
+
 /pages/Welcome.jsp
 
 

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=389964&r1=389963&r2=389964&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/WEB-INF/web.xml Wed 
Mar 29 18:08:10 2006
@@ -26,7 +26,7 @@
 mailreader2.ApplicationListener
 
 
-
+   
 
 index.html
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/w

Re: [Struts Ti] XWork?

[Frank W. Zammetti]

This could be a valuable comment... or maybe it won't be :) ... this is 
coming from the perspective of an experienced Struts developer who has 
looked at and worked with Webwork just a bit at this point, so take it 
for what it's worth...


I didn't, before some reading I just did, have a separation in my mind 
between Webwork and XWork.  What I had in my own mind as an 
understanding of Webwork was really the combination of Webwork and XWork.


From that perspective, I'm not sure I see how *not* bringing XWork over 
with Webwork would yield something comparable to Struts.  It seems like 
if Action2 is really going to be the next Struts, it necessarily has to 
be both Webwork and XWork combined, otherwise it's something... less.


I suppose there might be ways to bring Webwork over without XWork 
initially, but to me that seems like more work in the long run (maybe 
not for me, but I wouldn't think anyone wants to do more work than is 
necessary :) ).


I have to believe that the Struts team has a better understanding than I 
do of what Webwork is and how XWork relates.  But can the same be said 
of the Struts user community?  Could it possibly be that even the 
Webwork community doesn't fully understand?  I ask these rhetorically 
only to illustrate the point, which is that I suspect that for a lot of 
developers, there won't be a distinction between Webwork and XWork, like 
there wasn't for me, so it is probably best for XWork to come over too, 
and concurrently with Webwork.


Besides, what is the alternative if it doesn't?  Will the Struts 
download page point you to the XWork download page at OpenSymphony as a 
dependency?


I hope that perspective is useful :)

Frank

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

Important note: this does not mean merging Webwork and XWork, just making them 
two subsections of Struts Action 2.0.

Other important notes: The functionality of Struts 1.* is equivalent to XWork + 
Webwork not just Webwork, and without XWork SAF 2 would be an action framework 
without an action class.

Making that decision is very important in determining other things as they come 
up. The recent example is package naming. If we put Webwork code at 
some.struts.action2.root package, then where would XWork go? I strongly suspect 
there will be other decisions made that will similarly be better done if we 
know whether XWork would be a part of Struts Action 2.0.

Recent events support the Struts Action 2.0 = Webwork + XWork argument. There 
was the question of whether a ForwardAction should be created or how it related 
to XWORK's ActionSupport. I suspect that a lot of these questiosn of how Struts 
Classic compares to XWork will need to be asked in the future not only by 
struts developers but also by those interested in moving from Struts Classic to 
Struts Action 2.0. We will get tons of questions about how Actions / 
configuration compare from Struts Classic to XWork's, want to provide migration 
strategies from struts-configs to xwork-configs from struts ActionSupport to 
xwork ActionSupport.

This means that advantages of moving XWork at the same time as Webwork are:
1) one users list to deal with user comments on both Action issues (XWork) and 
Tag/view issues (Webwork)
2) The ability to coordinate releases or add features (For example the 
ForwardAction) that will help Struts Classic users migrate to Action 2. 
(Currently, it should be noted, XWork and Webwork releases happen pretty much 
simultaneously with an XWork version coming out and then a Webwork.)
3) The ability for documentation for Action 2 to more gracefully contain 
integrated documentation on its action structure.

I think going forward, if you are opposed to bringing XWork in immediately, 
then the following questions should be answered:
1) How would XWork questions be answered? Would the struts list serve as a 
second xwork mailing list or would questions be forwarded to opensymphony?
2) Would large amounts of struts documentation serve to duplicate XWork 
documentation or would struts developers be forwarded to xwork documentation?

It is important to decide those issues, because for a new 'revolutionary' approach, we wouldn't want to switch midstream how users approach XWork classes (start out with open symphony ActionSupport and then have to move to a struts one for example), since they are so integral to the app. 


I hope this clarifies why I think this is a decision we should make now.

Gabe














- Original Message 
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Saturday, March 25, 2006 5:22:47 PM
Subject: Re: [Struts Ti] XWork?

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

I'm sure I could come up with more reasons, but this is a good start to this 
discussion.


I

Re: [Struts Ti] XWork?

[Jeff Turner]

On Wed, Mar 29, 2006 at 06:03:56PM -0800, 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

If that's even a *possibility* then I guess I should reimport JIRA data
from OpenSymphony, and this time not delete XWork. Merging in XWork later
isn't an option.

I'll do this later today, just in case.


--Jeff

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

Re: [Struts Ti] XWork?

[Craig McClanahan]

On 3/25/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 3/25/06, Gabe <[EMAIL PROTECTED]> wrote:
> > I'm sure I could come up with more reasons, but this is a good start to
> this discussion.
>
> I don't think anyone would have a problem with this, Gabe. It's just a
> matter of whether we need to bring XWork and WebWork through
> simultaneously, or whether we can do them one and then the other. (If
> that's what the XWork developers would like.)


And that parenthetical comment is the key to this.  Nothing stops SAF
2.0(or Shale for that matter) from having a binary dependency on
XWork, even if
it is still maintained by the OpenSymphony folks. I would personally welcome
including this code base ... but whether it comes here or stays there has to
start with what the XWork developers want to do.

Craig

Re: [Struts Ti] XWork?

[Don Brown]

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]

RE: SV: Struts 1.3 and Internationalization

[hermod.opstvedt]

Hi

I found the old thread : 
http://servlets.com/archive/servlet/ReadMsg?msgId=479384&listName=struts-user

There was not raised an issue back then.

Hermod

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 30, 2006 12:17 AM
To: Hermod Opstvedt; 'Struts Developers List'
Subject: Re: SV: Struts 1.3 and Internationalization


At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
>This is a BeanUtils issue. ...
>
>This is a user-list topic and should probably move there.

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't be pushed to a method 
which takes a locale as an argument, and this method amended to call 
that one with the system default locale.

Then, the few places where RequestUtils.populate is called could be 
refactored to pass in the session locale if it is available, then 
line 451 cited above could be changed to make a new instance of 
LocaleBeanUtilsBean with the current locale.  (I've never used the 
localized bean utils code, but I think this is basically how it is to 
be done...)

and that method is only called in three places, one of which passes 
along from an alternate signature in RequestUtils.  The other two 
places are in the base RequestProcessor and the PopulateActionForm 
command (which essentially obsoletes the RequestProcessor.)

One possible compatibility issue would be with how instances of 
LocaleBeanUtilsBean interact with statically registered converters -- 
if people have existing apps that register converters statically, I 
don't think that those would be picked up by a newly instantiated 
LocaleBeanUtilsBean -- which would bring up the deeper issue of 
registering converters for different situations, which may well be 
where things got mired down before?  I don't recall earlier 
discussion of the issue.

If nothing else, Hermod, could you check issues.apache.org for any 
possibly existing ticket, and if you don't find one, create one?  It 
would be better to have this discussion in the bug tracker so that it 
is archived in conjunction with the actual enhancement request.

Joe



At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
>Hi
>
>Not quite - If you have an html:text field, and enter a number with a comma
>as decimal separator, and then try to access it in your action from the form
>it will be null. Just go ahead and try it. As far as I remember, the "wont
>touch" reasoning had to do with some code deep down in Struts not being able
>to access the locale from the request, and adding support would mean no
>backward compatibility. Correct me if I am wrong. It is quite some time
>since I ran into this (1.2.2 or something), and I solved it by hacking the
>html:text tag and some other places I do not remember.


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


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


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

Re: [Struts Ti] XWork?

[Frank W. Zammetti]

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

Don Brown wrote:

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]






--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

RE: SV: Struts 1.3 and Internationalization

[hermod.opstvedt]

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

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't be pushed to a method
> > which takes a locale as an argument, and this method amended to call
> > that one with the system default locale.
>
> I would agree if we weren't recommending that people use Strings in
> the ActionForm [1].


Exactly. The "best practice" ever since Struts was created has been to use
strings for form fields, specifically so that you have the exact original
value to present to the user in an error situation. Once you bring other
data types into the picture, you can no longer guarantee that you can
redisplay exactly what the user (mis-)typed.

--
Martin Cooper


What I'm saying is that your form should have String values and
> RequestUtils.populate() will populate it whatever your user typed in,
> and then in your Action you can use BeanUtils or FormDef to properly
> parse that into your business object typed field.
>
> You can see this in action in the locale.war demo of FormDef [2].
>
> > Joe
>
> Hubert
>
> [1] "... properties used with the html:text tag should still be String
> properties."
> http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> [2] http://www.rabago.net/struts/formdef/downloads.htm
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


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

Re: [Struts Ti] XWork?

[Ted Husted]

On 3/30/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Ted threw out the idea to WebWork for their team to merge forces and work on 
> Ti

Well, Patrick mentioned in the "Web alignment group" that WebWork
would like to join forces with another project, and we went from
there. We discussed with Jason and Patrick the idea of going forward
with Clarity, but they preferred the idea of joining Apache Struts.
For the sake of continuity, we then made the WebWork merger the first
phase of "Ti".

All the background is still here:

* http://opensource.atlassian.com/confluence/oss/display/STRUTS2/Home

The first phase of Ti is to bring WebWork over to Struts Action
essentially as is. Which is to say, WebWork 2.3 will be Struts Action
2.0 The second phase is to pursue the (ongoing) goal to "create a new
simpler, more feature-rich developer-centric framework".

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

-Ted.

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

Re: SV: Struts 1.3 and Internationalization

[Martin Cooper]

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't be pushed to a method
> > > which takes a locale as an argument, and this method amended to call
> > > that one with the system default locale.
> >
> > I would agree if we weren't recommending that people use Strings in
> > the ActionForm [1].
>
>
> Exactly. The "best practice" ever since Struts was created has been to use
> strings for form fields, specifically so that you have the exact original
> value to present to the user in an error situation. Once you bring other
> data types into the picture, you can no longer guarantee that you can
> redisplay exactly what the user (mis-)typed.
>
> --
> Martin Cooper
>
>
> What I'm saying is that your form should have String values and
> > RequestUtils.populate() will populate it whatever your user typed in,
> > and then in your Action you can use BeanUtils or FormDef to properly
> > parse that into your business object typed field.
> >
> > You can see this in action in the locale.war demo of FormDef [2].
> >
> > > Joe
> >
> > Hubert
> >
> > [1] "... properties used with the html:text tag should still be String
> > properties."
> >
> http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> > [2] http://www.rabago.net/struts/formdef/downloads.htm
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *
>
> This email with attachments is solely for the use of the individual or
> entity to whom it is addressed. Please also be aware that DnB NOR cannot
> accept any payment orders or other legally binding correspondence with
> customers as a part of an email.
>
> This email messa

Re: [Struts Ti] XWork?

[Ted Husted]

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]

Re: [Struts Ti] XWork?

[Frank W. Zammetti]

That's exactly what I had in mind, thanks for the reference.  I see the 
source of the confusion (phase I vs. II as you say).  At least now I can 
point people that ask me to the right place :)


Frank

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]






--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!

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

RE: SV: Struts 1.3 and Internationalization

[hermod.opstvedt]

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.

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't be pushed to a method
> > > which takes a locale as an argument, and this method amended to call
> > > that one with the system default locale.
> >
> > I would agree if we weren't recommending that people use Strings in
> > the ActionForm [1].
>
>
> Exactly. The "best practice" ever since Struts was created has been to use
> strings for form fields, specifically so that you have the exact original
> value to present to the user in an error situation. Once you bring other
> data types into the picture, you can no longer guarantee that you can
> redisplay exactly what the user (mis-)typed.
>
> --
> Martin Cooper
>
>
> What I'm saying is that your form should have String values and
> > RequestUtils.populate() will populate it whatever your user typed in,
> > and then in your Action you can use BeanUtils or FormDef to properly
> > parse that into your business object typed field.
> >
> > You can see this in action in the locale.war demo of FormDef [2].
> >
> > > Joe
> >
> > Hubert
> >
> > [1] "... properties used with the html:text tag should still be String
> > properties."
> >
> http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> > [2] http://www.rabago.net/struts/formdef/downloads.htm
> >
> > 

Re: [Struts Ti] XWork?

[Don Brown]

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

[Martin Cooper]

On 3/29/06, [EMAIL PROTECTED] <[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?


Well, if you're using strings in your form beans, per Struts best practices,
and the problem is in your (non-Struts) code that converts those strings to
other types, that's not exactly a Struts issue... It's an issue with
BeanUtils or the way you are using it. That would be a question for the
BeanUtils people, most of whom are on the Commons mailing lists rather than
here, since BeanUtils is a Commons component and not part of 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.


Even if the type conversions worked when the values were entered correctly,
your web app would not be able to correctly re-present the values the user
entered when they were entered incorrectly. For that, you _must_ use
strings.

--
Martin Cooper


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't be pushed to a method
> > > > which takes a locale as an argument, and this method amended to call
> > > > that one with the system default locale.
> > >
> > > I would agree if we weren't recommending that people use Strings in
> > > the ActionForm [1].
> >
> >
> > Exactly. The "best practice" ever since S

RE: SV: Struts 1.3 and Internationalization

[hermod.opstvedt]

Hi

Again: Full circle. What if we actually fixed this in Struts, meaning that we 
offer a Struts version of the BeanUtils (as is done for similar things in 
Shale) where we solve this so that you can have your cake and eat it.

Hermod

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


On 3/29/06, [EMAIL PROTECTED] <[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?


Well, if you're using strings in your form beans, per Struts best practices,
and the problem is in your (non-Struts) code that converts those strings to
other types, that's not exactly a Struts issue... It's an issue with
BeanUtils or the way you are using it. That would be a question for the
BeanUtils people, most of whom are on the Commons mailing lists rather than
here, since BeanUtils is a Commons component and not part of 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.


Even if the type conversions worked when the values were entered correctly,
your web app would not be able to correctly re-present the values the user
entered when they were entered incorrectly. For that, you _must_ use
strings.

--
Martin Cooper


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

Re: SV: Struts 1.3 and Internationalization

[Michael Jouravlev]

On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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.

Hubert :) Do you still stand your position that Struts users will use
any third-party extensions if they provide good features? ;) Here is
another example that proves that users want *standard distro* (WebWork
+ XWork is kind of the same thing). FormDef is pretty slick. I still
don't get why it is not in the base distro especially when base
ActionForm cannot offer more than it offered 5 years ago (talking
about stagnation). I guess chances of including FormDef into standard
package are pretty slim now considering WebWork thing.

I am sending this email to a public list just to bring attention to
Struts weakest point: input data conversion. Hubert has a good
extension, why not include it as eightth (sp?) dwarf into 1.3?

Michael.

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

svn commit: r390007 - in /struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages: Welcome.jsp tour.html

[husted]

Author: husted
Date: Wed Mar 29 22:41:20 2006
New Revision: 390007

URL: http://svn.apache.org/viewcvs?rev=390007&view=rev
Log:
Action2 Apps
* Mailreader Tour - Work in Progress
** Up to "Logon.do" 

Modified:
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp?rev=390007&r1=390006&r2=390007&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp 
Wed Mar 29 22:41:20 2006
@@ -21,14 +21,18 @@
 
 
 Language Options
-
-
-
 
 ">English
 ">Japanese
 ">Russian
 
+
+
+
+
+"
+ alt=""/>
+
 
 ">
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html?rev=390007&r1=390006&r2=390007&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/tour.html Wed 
Mar 29 22:41:20 2006
@@ -24,7 +24,7 @@
 
 
 
-The Action2 MailReader application is based on the 2.2.2 release of 
WebWork
+The Action2 MailReader application is based on the 2.2.2 release of 
OpenSymphony WebWork
 (now known as Struts Action 2).
 To follow along, you should install the MailReader application on your
 own development workstation (e.g. localhost).
@@ -37,7 +37,7 @@
 language, JavaBeans, web applications, and JavaServer Pages. For 
background on
 these technologies, see the
 http://struts.apache.org/struts-action/userGuide/preface.html";>
-Preface to the Struts Action 1 User Guide.
+Preface to the Action 1 User Guide.
 
 
 
@@ -141,7 +141,7 @@
 Service (JAAS) is recommended for most applications.
 (See the http://struts.apache.org/struts-action/userGuide/preface.html";>
-Preface to the Struts Action 1 User Guide for more about
+Preface to the Action 1 User Guide for more about
 authentification technologies.)
 
 
@@ -168,44 +168,45 @@
 When a web application loads,
 the container reads and parses the "Web Application Deployment
 Descriptor", or web.xml file.
-The Struts Action 2 Framework plugs into a web application via a servlet 
filter.
+Action 2 plugs into a web application via a servlet filter.
 Like any filter, the Action servlet is deployed via the web.xml.
 
 
 
 web.xml - The Web Application Deployment Descriptor
 
-
-%lt;display-name>Action2 Mailreader%lt;/display-name>
+
+%lt;display-name>Action2 Mailreader%lt;/display-name>
 
 %lt;filter>
-%lt;filter-name>action2%lt;/filter-name>
-%lt;filter-class>
-
com.opensymphony.webwork.dispatcher.FilterDispatcher%lt;/filter-class>
+%lt;filter-name>action2%lt;/filter-name>
+%lt;filter-class>
+com.opensymphony.webwork.dispatcher.FilterDispatcher%lt;/filter-class>
 %lt;/filter>
 
 %lt;filter-mapping>
-%lt;filter-name>action2%lt;/filter-name>
-%lt;url-pattern>/*%lt;/url-pattern>
+%lt;filter-name>action2%lt;/filter-name>
+%lt;url-pattern>/*%lt;/url-pattern>
 %lt;/filter-mapping>
 
 %lt;listener>
-%lt;listener-class>
-
org.springframework.web.context.ContextLoaderListener%lt;/listener-class>
+%lt;listener-class>
+org.springframework.web.context.ContextLoaderListener%lt;/listener-class>
 %lt;/listener>
 
 %lt;!-- Application Listener for Mailreader database -->
 %lt;listener>
-%lt;listener-class>
-mailreader2.ApplicationListener
-%lt;/listener-class>
+%lt;listener-class>
+mailreader2.ApplicationListener
+%lt;/listener-class>
 %lt;/listener>
 
 %lt;welcome-file-list>
-%lt;welcome-file>index.html%lt;/welcome-file>
+%lt;welcome-file>index.html%lt;/welcome-file>
 %lt;/welcome-file-list>
 
-%lt;/web-app>
+%lt;/web-app>
 
 
 
@@ -218,9 +219,8 @@
 
 
 
-Albeit, most Struts Action Framework applications do not refer to physical 
pages,
+Albeit, most Action 2 applications do not refer to physical pages,
 but