Re: [WebWork2] TODO

2006-03-27 Thread Alexandru Popescu 
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]

Re: WebWork and LGPL dependencies

2006-03-27 Thread Alexandru Popescu 
I know Theodor, he is a good friend of mine. Though, I think this decission
is more now on JaspectSoft than on Theodor. I will try to ping him and ask
about this. Are these threads available directly from the web, so that I can
point him to this discussion?

cheers,

./alex
--
.w( the_mindstorm )p.


On 3/28/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> I'm sure that we would want to talk to JasperSoft first, Martin.
>
> -Ted.
>
> On 3/27/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > If we want to do that, I'm willing to talk to them. I know the CTO of
> > JasperSoft and some other people there, although not the JasperReports
> guy
> > specifically. Let me know.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

2006-03-27 Thread Antonio Petrelli 

Craig McClanahan ha scritto:

One of the reasons I think using a Locale is a good choice is that you'll
need one later on anyway ... to generate Locale-sensitive date formats, for
example.


You're right. But the big problem is that Locale is a final class. I 
think that an "extensible" locale class could be useful. Using Locale 
class you're bound to that class. You can internationalize your Tiles 
definitions, that's true (for each locale you have different Tiles 
definition) but then you cannot separate definition, for example, by 
client device. It IS possible with Struts-Tiles (again through the use 
of FactorySet), because the "key" is an Object. The class I18NFactorySet 
extends FactorySet, take your conclusions...



It is also the mechanism used universally throughout Java for this
kind of decision.


I think Tiles definitions are not only a question of I18N...


  Finally, Struts already keeps track of the current Locale
for a user in a session variable, so it's easy to grab when you need it.
  


But instead of using Locale class, why Object can't be used? Is a class 
cast too costly?



(JSF and other frameworks do the same sort of thing too.)
  


Sorry but Tiles won't be Struts-Tiles anymore ;-)
Ciao
Antonio

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

Re: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Craig McClanahan 
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

Re: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Wendy Smoak 
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?

--
Wendy

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

svn commit: r389402 - /struts/site/trunk/xdocs/downloads.xml

2006-03-27 Thread wsmoak 
Author: wsmoak
Date: Mon Mar 27 21:35:00 2006
New Revision: 389402

URL: http://svn.apache.org/viewcvs?rev=389402&view=rev
Log:
Add a link to the Shale 1.0.2 Alpha release.

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

Modified: struts/site/trunk/xdocs/downloads.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/downloads.xml?rev=389402&r1=389401&r2=389402&view=diff
==
--- struts/site/trunk/xdocs/downloads.xml (original)
+++ struts/site/trunk/xdocs/downloads.xml Mon Mar 27 21:35:00 2006
@@ -69,6 +69,16 @@
 
 
 
+Alpha Releases
+
+
+http://cvs.apache.org/dist/struts/shale/v1.0.2";>
+Struts Shale 1.0.2
+
+
+
+
+
 Older Releases
 are available from the
 



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

DO NOT REPLY [Bug 38627] - [shale] ${htmlunit.home} breaks build

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-28 06:30 ---
(In reply to comment #7)
> HtmlUnit is available on ibiblio:
>http://www.ibiblio.org/maven2/htmlunit/htmlunit/
> 
> Is there any reason we would not want to retrieve it and commons-httpclient in
> the 'ant download-dependencies' task?
> 
> That was my plan, I just didn't want to risk changes before the release.
> 

That's fine for these two dependencies (which are sufficient for compiling), but
not for the other 27 gazillion dependencies that are rev dependent, and required
to run the "systest" test suites :-(.



-- 
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 38627] - [shale] ${htmlunit.home} breaks build

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-28 04:22 ---
HtmlUnit is available on ibiblio:
   http://www.ibiblio.org/maven2/htmlunit/htmlunit/

Is there any reason we would not want to retrieve it and commons-httpclient in
the 'ant download-dependencies' task?

That was my plan, I just didn't want to risk changes before the release.


-- 
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 38627] - [shale] ${htmlunit.home} breaks build

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-28 04:12 ---
Partially fixed in nightly build 20060328.  The overall "ant clean release"
should now build successfully even if htmlunit.home is not defined.

Be sure to review the changes to build.properties.sample if you *do* want to
compile with HtmlUnit -- you'll need to define two extra properties that are
rev-locked to which HtmlUnit version you are pointing at.

Before this issue can be closed, the changes to use-cases/build.xml (making
compile and execution of systests conditional on HtmlUnit being present) need to
be propogated to the other webapp build.xml scripts, so I'm leaving this open
for now.


-- 
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: r389377 - in /struts/shale/trunk: build.properties.sample test-framework/build.xml use-cases/build.xml

2006-03-27 Thread craigmcc 
Author: craigmcc
Date: Mon Mar 27 19:10:03 2006
New Revision: 389377

URL: http://svn.apache.org/viewcvs?rev=389377&view=rev
Log:
*Partial* fix for issue 38627 (undefined "htmlunit.home" breaks the build)
by changing the way that HtmlUnit is autodetected in test-framework/build.xml
(which was where the failure occurred).  You should now be able to do an
"ant clean release test" from the top level directory without setting
htmlunit.home -- although you'll want to review the changes to
build.properties.sample if you *do* have HtmlUnit available.

Also modified the use-cases/build.xml script to only compile and execute
system tests only if HtmlUnit is present.  These changes have to be propogated
to the other webapp build scripts before the issue can be closed.

PR:  Bugzilla #38627
Submitted By:  Dennis C. Byrnne 

Modified:
struts/shale/trunk/build.properties.sample
struts/shale/trunk/test-framework/build.xml
struts/shale/trunk/use-cases/build.xml

Modified: struts/shale/trunk/build.properties.sample
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/build.properties.sample?rev=389377&r1=389376&r2=389377&view=diff
==
--- struts/shale/trunk/build.properties.sample (original)
+++ struts/shale/trunk/build.properties.sample Mon Mar 27 19:10:03 2006
@@ -78,3 +78,11 @@
 
 # (Optional) The path to a Tomcat 5.0.x installation
 tomcat50.home=c:/java/jakarta-tomcat-5.0.28
+
+# (Optional) The following three declarations must be declared and updated
+# together, whenever we switch versions of HtmlUnit.  The following defaults
+# reflect HtmlUnit 1.6 (which is the currently expected version).
+htmlunit.home=/usr/local/htmlunit-1.6
+htmlunit.jar=htmlunit-1.6.jar
+commons-httpclient.jar=httpclient-3.0-rc2.jar
+

Modified: struts/shale/trunk/test-framework/build.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/test-framework/build.xml?rev=389377&r1=389376&r2=389377&view=diff
==
--- struts/shale/trunk/test-framework/build.xml (original)
+++ struts/shale/trunk/test-framework/build.xml Mon Mar 27 19:10:03 2006
@@ -80,8 +80,8 @@
 
 
 
-
+
+
   
 
 
@@ -92,7 +92,7 @@
   
 
 
-
+  
 
 
   http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/build.xml?rev=389377&r1=389376&r2=389377&view=diff
==
--- struts/shale/trunk/use-cases/build.xml (original)
+++ struts/shale/trunk/use-cases/build.xml Mon Mar 27 19:10:03 2006
@@ -114,14 +114,17 @@
 
   
   
-
-
+
+
+
 
   
 
 
   
+  
   
@@ -162,6 +165,7 @@
 
 
 
+
 
 
 
@@ -487,7 +491,8 @@
   
 
 
-  
+  
 
 
 
@@ -513,14 +518,20 @@
 
 
   
+   description="Execute system integration tests"
+if="htmlunit.present">
 
 
 
-  
+  
+
+
+
+

DO NOT REPLY [Bug 36054] - [struts-faces] Example 2 application does not get deployed properly.

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-03-28 04:02 ---
While resolving Bug 38955 I noted that both example apps start up and work
correctly.  I see the following in the Tomcat 4.1.31 console:

Mar 27, 2006 7:49:10 PM org.apache.struts.tiles.TilesPlugin 
initDefinitionsFactory
INFO: Tiles definition factory loaded for module ''.

Feel free to reopen this if the example apps are still not working for you.

-- 
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: r389371 - /incubator/webwork2/STATUS.txt

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 18:51:43 2006
New Revision: 389371

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

Modified:
incubator/webwork2/STATUS.txt

Modified: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=389371&r1=389370&r2=389371&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 18:51:43 2006
@@ -30,8 +30,9 @@
 * Is this a server-side compoonent, or is there a Dojo equivalent?
 
 JasperReports
-* Can we do a bridge API for this? Or must be it be separate extension?
-* Would DataVision be an alternative (http://datavision.sourceforge.net/)?
+* Martin will contact Jasper software about license change
+** Alternatively, can we do a bridge API for this? Or must be it be separate 
extension?
+** Would DataVision be an alternative (http://datavision.sourceforge.net/)?
 
 
 



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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 18:49:39 2006
New Revision: 389370

URL: http://svn.apache.org/viewcvs?rev=389370&view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
** Add i18n support for coded fields 
** Add Javascript to set form focus


Added:

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/RegistrationSave-validation.xml
   (with props)

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/RegistrationSave.java
   (with props)

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Subscription-validation.xml
   (with props)
Modified:
struts/sandbox/trunk/action2/README.txt

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

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration-validation.xml

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

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=389370&r1=389369&r2=389370&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Mon Mar 27 18:49:39 2006
@@ -77,16 +77,13 @@
 Logon
 
 Nominal
-- Cancel (*)
++ Cancel
 + Reset
 - Submit (invalid) (*)
 + Submit (incorrect)
 + Submit
 
 Issues
-* Cancel
-** Cancel logs exceptions since the target properties on not on cancel action
-
 * Submit (invalid)
 ** The "errors.password.mismatch" is not being resolved as message
 
@@ -104,7 +101,7 @@
 Issues
 * Submit - no change
 ** Password is displayed in plain text
-** Is there a WW way to set the focus?
+** Is there a WW way to set the focus? (Asked in forum)
 * Edit - Submit (change)
 ** Password doesn't change when edited
 ** Password Confirmation message not displayed
@@ -142,11 +139,8 @@
 Logoff
 
 Nominal
-* Logoff - Refresh
-* Logoff - Skip to Registeration page (*)
-
-Issues
-* Skip to Registration - Displays blank Main Menu; Edit defaults to Create
++ Logoff - Refresh
++ Logoff - Skip to Registeration page
 
 
 
@@ -155,20 +149,17 @@
 Nominal
 + Cancel
 + Reset
-- Submit (no data)  (*)
-+ Submit (invalid data)
++ Submit (no data)
++ Submit (invalid data) (*)
 + Submit (data)
 - Submit (duplicate data) (*)
   Double submit
 
 Issues (*)
-* Submit
-** Not parsing message variables: {0} in the range {1}
-* Submit (duplidate data)
-** Fails silently for duplicate user name
-** Password Confirmation message not displayed
 * Submit (invalid data)
 ** When client-side validation is enabled, messages stack up on multiple 
invalid submits. Sever-side only OK.
+* Submit (duplidate data)
+** Fails silently for duplicate user name
 
 
 

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=389370&r1=389369&r2=389370&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
 Mon Mar 27 18:49:39 2006
@@ -318,7 +318,7 @@
 user = null;
 }
 if (user == null) {
-this.addFieldError("password", "error.password.mismatch");
+this.addFieldError("password", getText("error.password.mismatch"));
 }
 return user;
 }

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration-validation.xml
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration-validation.xml?rev=389370&r1=389369&r2=389370&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration-validation.xml
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration-validation.xml
 Mon Mar 27 18:49:39 2006
@@ -8,24 +8,6 @@
 
 
 
-
-
-
-
-
-true
-4
-10
-
-
-
-
-
-
-
-
-
-
 
 
 
@@ -46,10 +28,5 @@
 
 
 
-
-
-password eq password2
-
-
 
 

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

DO NOT REPLY [Bug 38955] - [struts-faces] Example application doesn't deploy

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-03-28 03:48 ---

Fixed in r389368 for the 20060328 nightly build.

   http://svn.apache.org/viewcvs?rev=389368&view=rev

I added source and target attributes to all the javac tasks, so we should now be
targetting 1.3 for all the binaries.  Both examples deploy and work in Tomcat
4.1.31 w/ JDK 1.4.2 even though I built the project with 1.5.0.  

Thanks for your patience. :)

-- 
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: r389368 - in /struts/faces/trunk: core-library/build.xml default.properties example1-webapp/build.xml example2-webapp/build.xml sysclient-app/build.xml systest1-webapp/build.xml

2006-03-27 Thread wsmoak 
Author: wsmoak
Date: Mon Mar 27 18:43:25 2006
New Revision: 389368

URL: http://svn.apache.org/viewcvs?rev=389368&view=rev
Log:
Add source and target attributes to all  tasks to target JDK 1.3.
Both example webapps now deploy properly in Tomcat 4.1.31 using JDK 1.4.2.
Bug: 38955
Reported By: Roland 

Added:
struts/faces/trunk/default.properties   (with props)
Modified:
struts/faces/trunk/core-library/build.xml
struts/faces/trunk/example1-webapp/build.xml
struts/faces/trunk/example2-webapp/build.xml
struts/faces/trunk/sysclient-app/build.xml
struts/faces/trunk/systest1-webapp/build.xml

Modified: struts/faces/trunk/core-library/build.xml
URL: 
http://svn.apache.org/viewcvs/struts/faces/trunk/core-library/build.xml?rev=389368&r1=389367&r2=389368&view=diff
==
--- struts/faces/trunk/core-library/build.xml (original)
+++ struts/faces/trunk/core-library/build.xml Mon Mar 27 18:43:25 2006
@@ -29,6 +29,7 @@
   
   
   
+  
   
 
 
@@ -186,7 +187,9 @@
destdir="${build.home}/classes"
  debug="${compile.debug}"
deprecation="${compile.deprecation}"
-  optimize="${compile.optimize}">
+  optimize="${compile.optimize}"
+source="${platform.source}"
+target="${platform.target}">
   
 
 
@@ -296,7 +299,9 @@
destdir="${build.home}/test-classes"
  debug="${compile.debug}"
deprecation="${compile.deprecation}"
-  optimize="${compile.optimize}">
+  optimize="${compile.optimize}"
+source="${platform.source}"
+target="${platform.target}">
   
 
 

Added: struts/faces/trunk/default.properties
URL: 
http://svn.apache.org/viewcvs/struts/faces/trunk/default.properties?rev=389368&view=auto
==
--- struts/faces/trunk/default.properties (added)
+++ struts/faces/trunk/default.properties Mon Mar 27 18:43:25 2006
@@ -0,0 +1,25 @@
+# default.properties
+# ---
+#
+# 
==
+# Copyright 2006 The Apache Software Foundation.
+# 
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+# 
+#  http://www.apache.org/licenses/LICENSE-2.0
+# 
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+# 
==
+
+# Java platform version which source code must conform to
+platform.source=1.3
+
+# Java platform version which generated class files must conform to
+platform.target=1.3
+

Propchange: struts/faces/trunk/default.properties
--
svn:eol-style = native

Modified: struts/faces/trunk/example1-webapp/build.xml
URL: 
http://svn.apache.org/viewcvs/struts/faces/trunk/example1-webapp/build.xml?rev=389368&r1=389367&r2=389368&view=diff
==
--- struts/faces/trunk/example1-webapp/build.xml (original)
+++ struts/faces/trunk/example1-webapp/build.xml Mon Mar 27 18:43:25 2006
@@ -29,6 +29,7 @@
   
   
   
+  
   
 
 
@@ -272,7 +273,9 @@
destdir="${build.home}/${context.path}/WEB-INF/classes"
  debug="${compile.debug}"
deprecation="${compile.deprecation}"
-  optimize="${compile.optimize}">
+  optimize="${compile.optimize}"
+source="${platform.source}"
+target="${platform.target}">
   
 
 

Modified: struts/faces/trunk/example2-webapp/build.xml
URL: 
http://svn.apache.org/viewcvs/struts/faces/trunk/example2-webapp/build.xml?rev=389368&r1=389367&r2=389368&view=diff
==
--- struts/faces/trunk/example2-webapp/build.xml (original)
+++ struts/faces/trunk/example2-webapp/build.xml Mon Mar 27 18:43:25 2006
@@ -29,6 +29,7 @@
   
   
   
+  
   
 
 
@@ -252,7 +253,9 @@
destdir="${build.home}/${context.path}/WEB-INF/classes"
  debug="${compile.debug}"
deprecation="${compile.deprecation}"
-  optimize="${compile.optimize}">
+  optimize="${compile.optimize}"
+source="${platform.source}"
+target="${platform.target}">
   
 
 

Modified: struts/faces/trunk/sysclient-app/build.xml
URL: 
http://svn.apache.org/view

Re: WebWork and LGPL dependencies

2006-03-27 Thread Ted Husted 
I'm sure that we would want to talk to JasperSoft first, Martin.

-Ted.

On 3/27/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> If we want to do that, I'm willing to talk to them. I know the CTO of
> JasperSoft and some other people there, although not the JasperReports guy
> specifically. Let me know.

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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Jonathan Revusky 

Gabe wrote:

I agree with Don and Paul. The webwork as dear to us as it may be should be 
excised.

- Original Message 
From: Paul Benedict <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, March 27, 2006 3:55:50 PM
Subject: Re: WebWork renaming strategy *revised*

I am +1 with Don. If this community wants the name webwork,


A package name, in particular, at the third or fourth level of a package 
hierarchy, is not a product's name. At least not necessarily. (It could 
be by coincidence.) It's just a package name.


So all of this is based on a first-rate logical fallacy.

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/

 then I believe this
incubation shouldn't become Struts 2.0 -- because names are well-established out 
there and it's awkward to say it's Struts although the packages are webwork;

you might as well just make it Apache WebWork and allow Action 2.0 to come from
another source base... but I don't think anyone wants to seriously do that ;)
The ball is rolling, so I recommend to "excise" the name WW from the product 
(in favor of "action2") unless you want to call it WW 2.3. -- Paul


--- Don Brown <[EMAIL PROTECTED]> wrote:



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

Re: WebWork and LGPL dependencies

2006-03-27 Thread Martin Cooper 
On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>
> Ted,
> thanks for clearifying this...
> Just removed the hibernate dep from ivy/pom. Hibernate was not used
> within the codebase, only in the docs.
> Do the docs need to be cleared as well from those deps (just the written
> docs, not code samples)?
>
> Has anyone yet talked to the JasperReports guy?


If we want to do that, I'm willing to talk to them. I know the CTO of
JasperSoft and some other people there, although not the JasperReports guy
specifically. Let me know.

--
Martin Cooper


This would be a dependency really hard to replace...
>
> cheers,
> Rainer
>
> > On 3/25/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> >> How should those be "refactored"? Is there a guideline available for
> >> removing the "bad" deps?
> >
> > First, we should contact the authors and make sure they do want to put
> > the code under the LGPL. Sometimes people use that as a default and
> > don't actually care.
> >
> > If the author does care, then we have to find or create comparable
> > technology under a license that we can bundle with the Apache License,
> > without trespassing on anyone's IP.
> >
> > -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: r389333 - in /struts/sandbox/trunk/action2: README.txt apps/mailreader/src/webapp/pages/Logon.jsp apps/mailreader/src/webapp/pages/Registration.jsp apps/mailreader/src/webapp/pages/Subscri

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 16:44:16 2006
New Revision: 389333

URL: http://svn.apache.org/viewcvs?rev=389333&view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
** Add ActionError tags to display validations not coupled with a single field. 

Modified:
struts/sandbox/trunk/action2/README.txt
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=389333&r1=389332&r2=389333&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Mon Mar 27 16:44:16 2006
@@ -77,13 +77,16 @@
 Logon
 
 Nominal
-+ Cancel
+- Cancel (*)
 + Reset
 - Submit (invalid) (*)
 + Submit (incorrect)
 + Submit
 
 Issues
+* Cancel
+** Cancel logs exceptions since the target properties on not on cancel action
+
 * Submit (invalid)
 ** The "errors.password.mismatch" is not being resolved as message
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp?rev=389333&r1=389332&r2=389333&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp Mon 
Mar 27 16:44:16 2006
@@ -11,6 +11,7 @@
 
 
 
+
 
 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp?rev=389333&r1=389332&r2=389333&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp 
(original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp 
Mon Mar 27 16:44:16 2006
@@ -16,6 +16,7 @@
 
 
 
+
 
 
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp?rev=389333&r1=389332&r2=389333&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp 
(original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp 
Mon Mar 27 16:44:16 2006
@@ -18,6 +18,8 @@
 
 
 
+
+
 
 
 



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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 16:22:41 2006
New Revision: 389327

URL: http://svn.apache.org/viewcvs?rev=389327&view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
** Add support for Locale change  
** Change Subscription workflow to validate edit/delete from base class. Save 
is validated from subclass.

Removed:
struts/sandbox/trunk/action2/STATUS.txt
Modified:
struts/sandbox/trunk/action2/README.txt
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties

struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties
struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties

struts/sandbox/trunk/action2/apps/mailreader/src/java/resources_ja.properties

struts/sandbox/trunk/action2/apps/mailreader/src/java/resources_ru.properties
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=389327&r1=389326&r2=389327&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Mon Mar 27 16:22:41 2006
@@ -184,7 +184,4 @@
 * Need to log and present unexpected exceptions
 
 
-
-
-
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties?rev=389327&r1=389326&r2=389327&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate.properties 
Mon Mar 27 16:22:41 2006
@@ -1,3 +1,3 @@
-prompt.password=Enter your Password here ==>
+password=Enter your Password here ==>
 struts.logo.path=/struts-power.gif
 struts.logo.alt=Powered by Struts

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties?rev=389327&r1=389326&r2=389327&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties 
(original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/alternate_ja.properties 
Mon Mar 27 16:22:41 2006
@@ -1 +1 @@
-prompt.password=\u30d1\u30b9\u30ef\u30fc\u30c9\u3092\u5165\u529b==>
+.password=\u30d1\u30b9\u30ef\u30fc\u30c9\u3092\u5165\u529b==>

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties?rev=389327&r1=389326&r2=389327&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties 
(original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/resources.properties 
Mon Mar 27 16:22:41 2006
@@ -54,17 +54,18 @@
 mainMenu.title=MailReader Demonstration Application - Main Menu
 option.imap=IMAP Protocol
 option.pop3=POP3 Protocol
-prompt.autoConnect=Auto Connect
-prompt.fromAddress=From Address
-prompt.fullName=Full Name
-prompt.mailHostname=Mail Server
-prompt.mailPassword=Mail Password
-prompt.mailServerType=Server Type
-prompt.mailUsername=Mail Username
-prompt.password=Password
-prompt.password2=(Repeat) Password
-prompt.replyToAddress=Reply To Address
-prompt.username=Username
+# prompt.
+autoConnect=Auto Connect
+fromAddress=From Address
+fullName=Full Name
+mailHostname=Mail Server
+mailPassword=Mail Password
+mailServerType=Server Type
+mailUsername=Mail Username
+password=Password
+password2=(Repeat) Password
+replyToAddress=Reply To Address
+username=Username
 registration.addSubscription=Add
 registration.deleteSubscription=Delete
 registration.editSubscription=Edit
@@ -75,18 +76,18 @@
 subscription.title.edit=Edit Existing Mail Subscription
 
 # Standard error messages for validator framework checks
-errors.required={0} is required.
-errors.minlength={0} cannot be less than {1} characters.
-errors.maxlength={0} cannot be greater than {1} characters.
-errors.invalid={0} is invalid.
-errors.byte={0} must be an byte.
-errors.short={0} must be an short.
-errors.integer={0} must be an integer.
-errors.long={0} must be an long.
-errors.float={0} must be an float.
-errors.double={0} must be an double.
-errors.date={0} is not a date.
-errors.range={0} is not in the range {1} through {2}.
-errors.creditcard={0} is not a valid credit card number.
-errors

Re: WebWork and LGPL dependencies

2006-03-27 Thread Frank W. Zammetti 

Indeed I do :)

And actually, some interesting things are happening there... Jim Menard, 
the creator of DataVision, is stepping away from it for lack of time. 
He has asked for volunteers to kind of take over (I offered to, as part 
of a team effort).  I wonder if he might be amenable to donating it to 
Apache outright?  That would not only serve the DataVision community, 
but would help here, and AFAIK would be the only report writer at Apache 
(I'm sure I'm missing a project somewhere!)


I'd probably have to say it isn't quite at the level of polish of 
JasperReports, but it *is* quite good.


Anyone should feel perfectly free to ping me for any reason if there is 
interest in going that route.  I'll help however I can.


Frank

Ted Husted wrote:

On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:

Has anyone yet talked to the JasperReports guy?
This would be a dependency really hard to replace...


One alternative might be DataVision.

* http://datavision.sourceforge.net/

Our friend Frank Zammetti  knows a little bit about it :)

-Ted.





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

Reading too much into java package names

2006-03-27 Thread Jonathan Revusky 

Don Brown wrote:
If we used the 'webwork' name in the package, I think we should abandon 
the idea of this being the second major version of Action. 


Don,

Java packages are just a technical disposition for avoiding name 
collisions. There is no actual necessity to have that there be a 
particularly strong correspondence between package (or class) names and 
the actual name of the product on the box (or the virtual box in this case.)


Now, there is a convention (that is only loosely followed out there) 
that the first parts of the package indicate where it can be found on 
the net. (As a practical matter, not a big deal, since google is your 
friend...)


But that convention would imply that the thing should start:

org.apache.*

or

org.apache.struts.*

since struts.apache.org is now considered some sort of umbrella, and 
besides, the struts.apache.org is the canonical website location, I 
guess. The above aspects follow an established convention and make 
perfect sense.


But, aside from that, in general, you can rename a java software product 
from foo to bar to baz for whatever marketing reasons without renaming 
*any* actual java packages.


Well, in short, I think you are reasoning on the basis of a logical 
fallacy. Given that java package names do not have the transcendental 
implications you attribute to them, maybe you should just let the 
webwork people decide on the package naming (after the org.apache.* 
part) -- it is that community's work after all.


Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/


In my 
opinion, a project needs to have a name, a single name, which one uses 
to identify it.  If we want to bring WebWork in as a new Struts 
subproject, and that is an option, then I'm fine with that.  However, 
I'm not OK with mixing webwork in with Action in with Struts.  We need 
to make a decision, then move on.


Don

Niall Pemberton wrote:


+1 to webwork - "org.apache.webwork" if thats allowed, otherwise
"org.apache.struts.webwork".

Niall

On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:


Hey there,

if webwork is an option as well, I would vote for org.apache.webwork :)

The tag prefix ui: won't be my choice... There are plenty of non-ui tags
within webwork. So this would result in something like: ui:/nonui: and
this would be quite annoying for me...
Same with html: prefix... Yes, some are html tags, but others are not...

So we would have to go the logic:, bean: and html: route...
Too much confusion...

Still my favourites are saf: or a: (and being sometimes lazy, ww: of
course :) )

cheers,
Rainer

PS: Can't we decide on this later if there is no consens now?
Since this is a simple refactoring with subversion it should not hold up
the incubation process for now...


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


+1

I would also be +1 to:
  - com.opensymphony.webwork package -> org.apache.struts.webwork or
org.apache.webwork
  - ww: tag prefix -> ui:



--
James Mitchell




On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:


STATUS so far

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

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

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

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

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

-Ted.

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



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




-
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: [WebWork2] TODO

2006-03-27 Thread Laurie Harper 

Joe Germuska wrote:

At 7:39 AM -0500 3/27/06, Ted Husted wrote:

Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?


I'm pretty sure there is not.


I haven't looked at the Walter Zorn tooltips, but Dojo does have a 
tooltip widget:


http://dojotoolkit.org/~dylan/dojo/tests/widget/test_Tooltip.html

Is that what would be needed?

L.


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

Re: WebWork and LGPL dependencies

2006-03-27 Thread Ted Husted 
On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> Has anyone yet talked to the JasperReports guy?
> This would be a dependency really hard to replace...

One alternative might be DataVision.

* http://datavision.sourceforge.net/

Our friend Frank Zammetti  knows a little bit about it :)

-Ted.

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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 14:39:14 2006
New Revision: 389316

URL: http://svn.apache.org/viewcvs?rev=389316&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=389316&r1=389315&r2=389316&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 14:39:14 2006
@@ -29,6 +29,10 @@
 tabbedpane.vm Archived UI template
 * Is this a server-side compoonent, or is there a Dojo equivalent?
 
+JasperReports
+* Can we do a bridge API for this? Or must be it be separate extension?
+* Would DataVision be an alternative (http://datavision.sourceforge.net/)?
+
 
 
 DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
@@ -42,13 +46,11 @@
 NAMING CONVENTIONS
 
 Option 1:
-
  - com.opensymphony.webwork package -> org.apache.struts.ti
  - WebWork* classes -> Struts*
  - WebWork in comments, documentation -> Struts Action 2
  - webwork. as the configuration properties prefix -> struts.
  - ww: tag prefix -> a:
-
 +1 Martin Cooper (binding)
 +0 Don Brown (binding)
 +1 Frank Zammetti  (non-binding)
@@ -59,28 +61,30 @@
  - WebWork in comments, documentation -> Struts Action 2
  - webwork. as the configuration properties prefix -> struts.
  - ww: tag prefix -> a:/saf:
-
 +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
-Brown (binding)
+Brown, James Mitchell (James is +1 for ui prefix) (binding)
 +0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
 +1 Paul Benedict, Michael Jouravlev (non-binding)
 
+Option 2b: 
+ - com.opensymphony.webwork package -> org.apache.[struts.]webwork
+ - otherwise same as option 2
++1 Niall Pemberton, Alexandru Popescu (Alexandru is +1 for ww: prefix)
++0 Joe Germuska, Ted Husted
+
 Option 3:
  - com.opensymphony.webwork package -> org.apache.web
  - WebWork in comments, documentation -> Struts Action 2
  - webwork. as the configuration properties prefix -> web
  - ww: tag prefix -> html: (Michael Jouravlev = +1 for html)
-
-+0 Joe Germuska, Ted Husted (binding) (both would not object to 
org.apache.webwork)
-+1 Gabed (non-binding)
++0 Joe Germuska, Ted Husted (binding)
++1 Gabe (non-binding)
 
 Option 4:
  - com.opensymphony.webwork package -> org.apache.webwork
  - WebWork in comments, documentation -> Struts Action 2
  - else, same as o.c.webwork
-
 +1 Scud (non-binding)
-
 
 
 



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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 14:32:45 2006
New Revision: 389314

URL: http://svn.apache.org/viewcvs?rev=389314&view=rev
Log:
Action2 Apps
* Mailreader - Work in progress
** Add support for Locale change  
** Change Subscription workflow to validate edit/delete from base class. Save 
is validated from subclass.

Removed:

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Subscription-delete-validation.xml

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Subscription-edit-validation.xml
Modified:
struts/sandbox/trunk/action2/README.txt

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

struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration.java
struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Logon.jsp
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/MainMenu.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Registration.jsp

struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Subscription.jsp
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/Welcome.jsp

Modified: struts/sandbox/trunk/action2/README.txt
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/README.txt?rev=389314&r1=389313&r2=389314&view=diff
==
--- struts/sandbox/trunk/action2/README.txt (original)
+++ struts/sandbox/trunk/action2/README.txt Mon Mar 27 14:32:45 2006
@@ -72,9 +72,6 @@
 + Logon - Cancel
 + Register - Cancel
 
-Issues
-* Powered image not displaying.
-
 
 
 Logon
@@ -173,7 +170,8 @@
 
 
 Locale change
-* TODO
++ Change locale from Welcome page.
++ Buttons and Labels reflect changed locale
 
 
 

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=389314&r1=389313&r2=389314&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
 Mon Mar 27 14:32:45 2006
@@ -332,7 +332,7 @@
  *  Persist the User object, including subscriptions, to the database.
  * 
  *
- * @throws javax.servlet.ServletException On any error
+ * @throws java.lang.Exception on database error
  */
 public void saveUser() throws Exception {
 try {

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration.java?rev=389314&r1=389313&r2=389314&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration.java
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/java/mailreader2/Registration.java
 Mon Mar 27 14:32:45 2006
@@ -4,8 +4,7 @@
 
 
 /**
- *  Provide an Edit method for retrieving an existing user, and a Save
- * method for updating or inserting a user. 
+ * Insert or update a User object to the persistent store. 
  */
 public final class Registration extends MailreaderSupport {
 

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=389314&r1=389313&r2=389314&view=diff
==
--- struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml (original)
+++ struts/sandbox/trunk/action2/apps/mailreader/src/java/xwork.xml Mon Mar 27 
14:32:45 2006
@@ -33,16 +33,6 @@
 ChangePassword
 
 
-
-
-/pages/MainMenu.jsp
-/pages/Logon.jsp
-ChangePassword
-
-
 
 /pages/ChangePassword.jsp
 

Modified: 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp?rev=389314&r1=389313&r2=389314&view=diff
==
--- 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
 (original)
+++ 
struts/sandbox/trunk/action2/apps/mailreader/src/webapp/pages/ChangePassword.jsp
 Mon Mar 27 14:32:45 2006
@@ -1,3 +1,4 @@
+<%@ page contentType="text/html; charset=UTF-8" %>
 <%@ taglib uri="/webwork"

Re: WebWork and LGPL dependencies

2006-03-27 Thread Ted Husted 
On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> Ted,
> thanks for clearifying this...
> Just removed the hibernate dep from ivy/pom. Hibernate was not used
> within the codebase, only in the docs.

Great!

> Do the docs need to be cleared as well from those deps (just the written
> docs, not code samples)?

If you mean mentioning the dependency in the documentation, no. It's
something we would have to do before a release. But it's not something
we need to do to clear the incubator.

We can *use* LGPL software to do our own work. The problem is we can't
*distribute* LGPL software, because the terms conflict with the more
liberal Apache License.

-Ted.

> Has anyone yet talked to the JasperReports guy?
> This would be a dependency really hard to replace...

This isn't our favorite option, but that could also be something that
was offered as an extension through SourceForge or Open Symphony. It
would not be maintained by the Apache Struts Project, though the same
indivduals might be involved.

Sometimes, it's also possible to provide a bridge API that would let
people use an extension like JasperReports if they downloaded the JAR
themselves. The bridge API would let us compile our code without
having the actual LPGL jar available. Again, this not something we
like to do, but it can be done if necessary.

I'll add JasperReports to the list.

-Ted.


>
> cheers,
> Rainer
>

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

Re: WebWork and LGPL dependencies

2006-03-27 Thread Don Brown 

We don't need to replace the Java code that depends on LGPL deps, as long as we:
 1. Don't download the LGPL dep jars in the normal build
 2. Don't ship the LGPL jars in our release

Therefore, I've split the build so that the classes that depend on LGPL jars won't be compiled in the standard build. 
You have to execute 'compile-optional' to pull down those LGPL jars and compile the related code.


The question is how this applies to unit tests.  If you interpret "default build" to be the one that runs when you just 
type "ant", then typing 'ant test' could pull down LGPL jars, compile the code and its unit tests without problems.  I'm 
pulling for this interpretation :)


Don

Rainer Hermanns wrote:

Ted,
thanks for clearifying this...
Just removed the hibernate dep from ivy/pom. Hibernate was not used
within the codebase, only in the docs.
Do the docs need to be cleared as well from those deps (just the written
docs, not code samples)?

Has anyone yet talked to the JasperReports guy?
This would be a dependency really hard to replace...

cheers,
Rainer


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

How should those be "refactored"? Is there a guideline available for
removing the "bad" deps?

First, we should contact the authors and make sure they do want to put
the code under the LGPL. Sometimes people use that as a default and
don't actually care.

If the author does care, then we have to find or create comparable
technology under a license that we can bundle with the Apache License,
without trespassing on anyone's IP.

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





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

Re: WebWork and LGPL dependencies

2006-03-27 Thread Rainer Hermanns 
Ted,
thanks for clearifying this...
Just removed the hibernate dep from ivy/pom. Hibernate was not used
within the codebase, only in the docs.
Do the docs need to be cleared as well from those deps (just the written
docs, not code samples)?

Has anyone yet talked to the JasperReports guy?
This would be a dependency really hard to replace...

cheers,
Rainer

> On 3/25/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>> How should those be "refactored"? Is there a guideline available for
>> removing the "bad" deps?
>
> First, we should contact the authors and make sure they do want to put
> the code under the LGPL. Sometimes people use that as a default and
> don't actually care.
>
> If the author does care, then we have to find or create comparable
> technology under a license that we can bundle with the Apache License,
> without trespassing on anyone's IP.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Rainer Hermanns 
Sorry if this was taken wrong...

I am all for Action 2, so I voted for org.apache.struts.action2 and
that is still my favourite for the package name...

So I am +1 with Don & Paul as well...

--
Rainer
>
> I agree with Don and Paul. The webwork as dear to us as it may be should
> be excised.
>
> - Original Message 
> From: Paul Benedict <[EMAIL PROTECTED]>
> To: Struts Developers List 
> Sent: Monday, March 27, 2006 3:55:50 PM
> Subject: Re: WebWork renaming strategy *revised*
>
> I am +1 with Don. If this community wants the name webwork, then I believe
> this
> incubation shouldn't become Struts 2.0 -- because names are
> well-established out
> there and it's awkward to say it's Struts although the packages are
> webwork;
> you might as well just make it Apache WebWork and allow Action 2.0 to come
> from
> another source base... but I don't think anyone wants to seriously do that
> ;)
> The ball is rolling, so I recommend to "excise" the name WW from the
> product
> (in favor of "action2") unless you want to call it WW 2.3. -- Paul
>
> --- Don Brown <[EMAIL PROTECTED]> wrote:
>
>> If we used the 'webwork' name in the package, I think we should abandon
>> the idea of this being
>> the second major version
>> of Action.  In my opinion, a project needs to have a name, a single
>> name, which one uses to
>> identify it.  If we want to
>> bring WebWork in as a new Struts subproject, and that is an option, then
>> I'm fine with that.
>> However, I'm not OK with
>> mixing webwork in with Action in with Struts.  We need to make a
>> decision, then move on.
>>
>> Don
>>
>> Niall Pemberton wrote:
>> > +1 to webwork - "org.apache.webwork" if thats allowed, otherwise
>> > "org.apache.struts.webwork".
>> >
>> > Niall
>> >
>> > On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>> >> Hey there,
>> >>
>> >> if webwork is an option as well, I would vote for org.apache.webwork
>> :)
>> >>
>> >> The tag prefix ui: won't be my choice... There are plenty of non-ui
>> tags
>> >> within webwork. So this would result in something like: ui:/nonui:
>> and
>> >> this would be quite annoying for me...
>> >> Same with html: prefix... Yes, some are html tags, but others are
>> not...
>> >>
>> >> So we would have to go the logic:, bean: and html: route...
>> >> Too much confusion...
>> >>
>> >> Still my favourites are saf: or a: (and being sometimes lazy, ww: of
>> >> course :) )
>> >>
>> >> cheers,
>> >> Rainer
>> >>
>> >> PS: Can't we decide on this later if there is no consens now?
>> >> Since this is a simple refactoring with subversion it should not hold
>> up
>> >> the incubation process for now...
>> >>
>>   - com.opensymphony.webwork package -> org.apache.struts.action2
>>   - WebWork* classes -> Struts*
>>   - WebWork in comments, documentation -> Struts Action 2
>>   - webwork. as the configuration properties prefix -> struts.
>>   - ww: tag prefix -> a:/saf:
>> >>> +1
>> >>>
>> >>> I would also be +1 to:
>> >>>   - com.opensymphony.webwork package -> org.apache.struts.webwork or
>> >>> org.apache.webwork
>> >>>   - ww: tag prefix -> ui:
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> James Mitchell
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
>> >>>
>>  STATUS so far
>> 
>>   - com.opensymphony.webwork package -> org.apache.struts.ti
>>   - WebWork* classes -> Struts*
>>   - WebWork in comments, documentation -> Struts Action 2
>>   - webwork. as the configuration properties prefix -> struts.
>>   - ww: tag prefix -> a:
>> 
>>  +1 Don Brown, Martin Cooper (binding)
>>  +1 Frank Zammetti  (non-binding)
>> 
>>   - com.opensymphony.webwork package -> org.apache.struts.action2
>>   - WebWork* classes -> Struts*
>>   - WebWork in comments, documentation -> Struts Action 2
>>   - webwork. as the configuration properties prefix -> struts.
>>   - ww: tag prefix -> a:/saf:
>> 
>>  +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
>>  (binding)
>>  +0 Toby Jee, Hubert Rabago (binding)
>>  +1 Paul Benedict (non-binding)
>> 
>>  If I've left any votes out, or gotten any of the votes wrong, be
>> sure
>>  to chime in!
>> 
>>  -Ted.
>> 
>>  -
>>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>>  For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>>
>> >>>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For a

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

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-27 22:21 ---
Created an attachment (id=17996)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17996&action=view)
Early draft of work to extract Struts initialization from ActionServlet
(gzipped tar file)


-- 
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 39040] - Refactor Struts initialization to ServletContextListener

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-27 22:19 ---
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!).  Since these are mostly new files, I'll attach a
tarball of what I have so far -- note that this is very much draft code.

I still haven't decided how to bootstrap the chain config itself, but that
shouldn't be a huge deal.  

-- 
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: r389249 - in /incubator/webwork2: build.xml ivy.xml pom.xml

2006-03-27 Thread hermanns 
Author: hermanns
Date: Mon Mar 27 12:08:17 2006
New Revision: 389249

URL: http://svn.apache.org/viewcvs?rev=389249&view=rev
Log:
removing dep retrieval for hibernate (notwhere used in the codebase)

Modified:
incubator/webwork2/build.xml
incubator/webwork2/ivy.xml
incubator/webwork2/pom.xml

Modified: incubator/webwork2/build.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/build.xml?rev=389249&r1=389248&r2=389249&view=diff
==
--- incubator/webwork2/build.xml (original)
+++ incubator/webwork2/build.xml Mon Mar 27 12:08:17 2006
@@ -234,7 +234,7 @@
 
 
 
-
+
 
 
 

Modified: incubator/webwork2/ivy.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/ivy.xml?rev=389249&r1=389248&r2=389249&view=diff
==
--- incubator/webwork2/ivy.xml (original)
+++ incubator/webwork2/ivy.xml Mon Mar 27 12:08:17 2006
@@ -41,7 +41,6 @@
 
 
 
-
 
 
 
@@ -150,7 +149,5 @@
 
 
 
-
-
 
 

Modified: incubator/webwork2/pom.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/pom.xml?rev=389249&r1=389248&r2=389249&view=diff
==
--- incubator/webwork2/pom.xml (original)
+++ incubator/webwork2/pom.xml Mon Mar 27 12:08:17 2006
@@ -127,7 +127,7 @@

svn commit: r389241 - /incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java

2006-03-27 Thread hermanns 
Author: hermanns
Date: Mon Mar 27 11:58:54 2006
New Revision: 389241

URL: http://svn.apache.org/viewcvs?rev=389241&view=rev
Log:
URL tag - includeParams default is "none", but docs states "get" is the default
Issue number: WW-1266
Obtained from: Nils-Helge Garli
Reviewed by: Rainer Hermanns

Modified:
incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java

Modified: 
incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java?rev=389241&r1=389240&r2=389241&view=diff
==
--- incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java 
(original)
+++ incubator/webwork2/src/java/org/apache/struts/action2/components/URL.java 
Mon Mar 27 11:58:54 2006
@@ -171,9 +171,11 @@
 }
 
 private void includeGetParameters() {
-String query = extractQueryString();
-if (query != null) {
-mergeRequestParameters(parameters, 
HttpUtils.parseQueryString(query));
+if(!(DispatcherUtils.isPortletSupportActive() && 
PortletActionContext.isPortletRequest())) {
+String query = extractQueryString();
+if (query != null) {
+mergeRequestParameters(parameters, 
HttpUtils.parseQueryString(query));
+}
 }
 }
 



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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Gabe 

I agree with Don and Paul. The webwork as dear to us as it may be should be 
excised.

- Original Message 
From: Paul Benedict <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, March 27, 2006 3:55:50 PM
Subject: Re: WebWork renaming strategy *revised*

I am +1 with Don. If this community wants the name webwork, then I believe this
incubation shouldn't become Struts 2.0 -- because names are well-established 
out 
there and it's awkward to say it's Struts although the packages are webwork;
you might as well just make it Apache WebWork and allow Action 2.0 to come from
another source base... but I don't think anyone wants to seriously do that ;)
The ball is rolling, so I recommend to "excise" the name WW from the product 
(in favor of "action2") unless you want to call it WW 2.3. -- Paul

--- Don Brown <[EMAIL PROTECTED]> wrote:

> If we used the 'webwork' name in the package, I think we should abandon the 
> idea of this being
> the second major version 
> of Action.  In my opinion, a project needs to have a name, a single name, 
> which one uses to
> identify it.  If we want to 
> bring WebWork in as a new Struts subproject, and that is an option, then I'm 
> fine with that. 
> However, I'm not OK with 
> mixing webwork in with Action in with Struts.  We need to make a decision, 
> then move on.
> 
> Don
> 
> Niall Pemberton wrote:
> > +1 to webwork - "org.apache.webwork" if thats allowed, otherwise
> > "org.apache.struts.webwork".
> > 
> > Niall
> > 
> > On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> >> Hey there,
> >>
> >> if webwork is an option as well, I would vote for org.apache.webwork :)
> >>
> >> The tag prefix ui: won't be my choice... There are plenty of non-ui tags
> >> within webwork. So this would result in something like: ui:/nonui: and
> >> this would be quite annoying for me...
> >> Same with html: prefix... Yes, some are html tags, but others are not...
> >>
> >> So we would have to go the logic:, bean: and html: route...
> >> Too much confusion...
> >>
> >> Still my favourites are saf: or a: (and being sometimes lazy, ww: of
> >> course :) )
> >>
> >> cheers,
> >> Rainer
> >>
> >> PS: Can't we decide on this later if there is no consens now?
> >> Since this is a simple refactoring with subversion it should not hold up
> >> the incubation process for now...
> >>
>   - com.opensymphony.webwork package -> org.apache.struts.action2
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:/saf:
> >>> +1
> >>>
> >>> I would also be +1 to:
> >>>   - com.opensymphony.webwork package -> org.apache.struts.webwork or
> >>> org.apache.webwork
> >>>   - ww: tag prefix -> ui:
> >>>
> >>>
> >>>
> >>> --
> >>> James Mitchell
> >>>
> >>>
> >>>
> >>>
> >>> On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
> >>>
>  STATUS so far
> 
>   - com.opensymphony.webwork package -> org.apache.struts.ti
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:
> 
>  +1 Don Brown, Martin Cooper (binding)
>  +1 Frank Zammetti  (non-binding)
> 
>   - com.opensymphony.webwork package -> org.apache.struts.action2
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:/saf:
> 
>  +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
>  (binding)
>  +0 Toby Jee, Hubert Rabago (binding)
>  +1 Paul Benedict (non-binding)
> 
>  If I've left any votes out, or gotten any of the votes wrong, be sure
>  to chime in!
> 
>  -Ted.
> 
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >> -
> >> 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 You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection a

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Paul Benedict 
I am +1 with Don. If this community wants the name webwork, then I believe this
incubation shouldn't become Struts 2.0 -- because names are well-established 
out 
there and it's awkward to say it's Struts although the packages are webwork;
you might as well just make it Apache WebWork and allow Action 2.0 to come from
another source base... but I don't think anyone wants to seriously do that ;)
The ball is rolling, so I recommend to "excise" the name WW from the product 
(in favor of "action2") unless you want to call it WW 2.3. -- Paul

--- Don Brown <[EMAIL PROTECTED]> wrote:

> If we used the 'webwork' name in the package, I think we should abandon the 
> idea of this being
> the second major version 
> of Action.  In my opinion, a project needs to have a name, a single name, 
> which one uses to
> identify it.  If we want to 
> bring WebWork in as a new Struts subproject, and that is an option, then I'm 
> fine with that. 
> However, I'm not OK with 
> mixing webwork in with Action in with Struts.  We need to make a decision, 
> then move on.
> 
> Don
> 
> Niall Pemberton wrote:
> > +1 to webwork - "org.apache.webwork" if thats allowed, otherwise
> > "org.apache.struts.webwork".
> > 
> > Niall
> > 
> > On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> >> Hey there,
> >>
> >> if webwork is an option as well, I would vote for org.apache.webwork :)
> >>
> >> The tag prefix ui: won't be my choice... There are plenty of non-ui tags
> >> within webwork. So this would result in something like: ui:/nonui: and
> >> this would be quite annoying for me...
> >> Same with html: prefix... Yes, some are html tags, but others are not...
> >>
> >> So we would have to go the logic:, bean: and html: route...
> >> Too much confusion...
> >>
> >> Still my favourites are saf: or a: (and being sometimes lazy, ww: of
> >> course :) )
> >>
> >> cheers,
> >> Rainer
> >>
> >> PS: Can't we decide on this later if there is no consens now?
> >> Since this is a simple refactoring with subversion it should not hold up
> >> the incubation process for now...
> >>
>   - com.opensymphony.webwork package -> org.apache.struts.action2
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:/saf:
> >>> +1
> >>>
> >>> I would also be +1 to:
> >>>   - com.opensymphony.webwork package -> org.apache.struts.webwork or
> >>> org.apache.webwork
> >>>   - ww: tag prefix -> ui:
> >>>
> >>>
> >>>
> >>> --
> >>> James Mitchell
> >>>
> >>>
> >>>
> >>>
> >>> On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
> >>>
>  STATUS so far
> 
>   - com.opensymphony.webwork package -> org.apache.struts.ti
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:
> 
>  +1 Don Brown, Martin Cooper (binding)
>  +1 Frank Zammetti  (non-binding)
> 
>   - com.opensymphony.webwork package -> org.apache.struts.action2
>   - WebWork* classes -> Struts*
>   - WebWork in comments, documentation -> Struts Action 2
>   - webwork. as the configuration properties prefix -> struts.
>   - ww: tag prefix -> a:/saf:
> 
>  +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
>  (binding)
>  +0 Toby Jee, Hubert Rabago (binding)
>  +1 Paul Benedict (non-binding)
> 
>  If I've left any votes out, or gotten any of the votes wrong, be sure
>  to chime in!
> 
>  -Ted.
> 
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>
> >> -
> >> 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 You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

[OT] Presentations from TSSJS 2006

2006-03-27 Thread Craig McClanahan 
Several people had asked me to post my slides for the two presentations I
did at The Server Side Java Symposium last week.  Pointers can be found at
the bottom ol my Apache home page:

http://people.apache.org/~craigmcc/

Craig

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Rainer Hermanns 
> However, I'm not OK with
> mixing webwork in with Action in with Struts.  We need to make a decision,
> then move on.
Yes, and the decision was to bring in webwork under the Struts umbrella as
Struts Action 2... And that's the route we should follow :)

Let's get back to developoment and bring us through the incubation process
soon...

cheers,
Rainer

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

Re: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Gary VanMatre 
>From: "Niall Pemberton" <[EMAIL PROTECTED]> 
>
> On 3/27/06, Craig McClanahan wrote: 
> > On 3/27/06, Niall Pemberton wrote: 
> > > 
> > > Sorry for the late vote - my vote is for "alpha" quality as well, mainly 
> > > for 
> > > the same "standalone tiles is not released" reason cited by others, but 
> > > also 
> > > because of the way Commons Validator has been implemented. It appears 
> > > that 
> > > the implementation was done based on an old version of validator where 
> > > the 
> > > javascript was embedded in the XML config file. This means that 1) 
> > > maintenance of that javascript is the responsibility of Shale and 2) 
> > > upgrading to later versions of validator (such as the 1.3.0 version just 
> > > released) won't pick up bugfixes in the javascript as users would expect. 
> > > Is 
> > > there any objection to changing Shale to use the javascript from Commons 
> > > Validator? 
> > 
> > 
> > +1 ... could you file an RFE so we can implement this and track it for the 
> > release notes on the next version? 
> 
> OK Done: 
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39121 
> 
> I'll try to get round to doing this in the next week or two, unless 
> someone beats me to it. 
> 

Since we are discussing validator issues, there is another an open 
validator bug that I created 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=37932)

I have not done anything with this yet.  We talked about making
a shale extension that you could create renderer decorators.  
I'm not so sure this is a great idea after discovering the 
tomahawk t:buffer component
(http://myfaces.apache.org/tomahawk/buffer.html).
I'm thinking that if we address this issue, it should only handle
the validator javascript for a cancel button.  

We talked about using a renderer decorator to add ajax type
support to vanilla components but this could be done with the
t:buffer too. 

Any thoughts?


Gary


> Niall 
> 
> > (I also plan on reviewing the other dependencies ... for example, MyFaces 
> > should be shipping 1.1.2 any day now, and it has a fix for the bug that 
> > prevents SQL Browser from actually displaying data.) 
> > 
> > Niall 
> > 
> > 
> > Craig 
> > 
> > - Original Message - 
> > > From: "Wendy Smoak" 
> > > Sent: Monday, March 27, 2006 6:13 AM 
> > > 
> > > 
> > > The vote results are as follows: 
> > > 
> > > Binding PMC Member votes: 
> > > Wendy Smoak - Alpha 
> > > Gary VanMatre - Alpha 
> > > Craig McClanahan - Alpha 
> > > 
> > > Non-binding: 
> > > Sean Schofield - Alpha 
> > > 
> > > Therefore, Shale 1.0.2 is designated as "Alpha" quality. 
> > > 
> > > Craig, as far as I can tell, there was never an announcement for Shale 
> > > 1.0.0, and it isn't in www.apache.org/dist/struts. What would you 
> > > like to see happen with this one? 
> > > 
> > > At this point, my only distribution plans are to put the test 
> > > framework jar on ibiblio (via www.apache.org/dist/maven-repository) so 
> > > that MyFaces can use it for their release. 
> > > 
> > > Thanks, 
> > > -- 
> > > Wendy 
> 
> - 
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED] 
>

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Alexandru Popescu 
This starts to look to take more time than we should put into it. Though,
once again as Rainer said, if webwork represents and option and also ww,
than I would cast my +1 for these. Considering that the Struts umbrella was
chosen and not the apache one, I guess the package names should be something
like: org.apache.struts.webwork.

cheers,

./alex
--
.w( the_mindstorm )p.


On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
>
> Hey there,
>
> if webwork is an option as well, I would vote for org.apache.webwork :)
>
> The tag prefix ui: won't be my choice... There are plenty of non-ui tags
> within webwork. So this would result in something like: ui:/nonui: and
> this would be quite annoying for me...
> Same with html: prefix... Yes, some are html tags, but others are not...
>
> So we would have to go the logic:, bean: and html: route...
> Too much confusion...
>
> Still my favourites are saf: or a: (and being sometimes lazy, ww: of
> course :) )
>
> cheers,
> Rainer
>
> PS: Can't we decide on this later if there is no consens now?
> Since this is a simple refactoring with subversion it should not hold up
> the incubation process for now...
>
> >>  - com.opensymphony.webwork package -> org.apache.struts.action2
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:/saf:
> >
> > +1
> >
> > I would also be +1 to:
> >   - com.opensymphony.webwork package -> org.apache.struts.webwork or
> > org.apache.webwork
> >   - ww: tag prefix -> ui:
> >
> >
> >
> > --
> > James Mitchell
> >
> >
> >
> >
> > On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
> >
> >> STATUS so far
> >>
> >>  - com.opensymphony.webwork package -> org.apache.struts.ti
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:
> >>
> >> +1 Don Brown, Martin Cooper (binding)
> >> +1 Frank Zammetti  (non-binding)
> >>
> >>  - com.opensymphony.webwork package -> org.apache.struts.action2
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:/saf:
> >>
> >> +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
> >> (binding)
> >> +0 Toby Jee, Hubert Rabago (binding)
> >> +1 Paul Benedict (non-binding)
> >>
> >> If I've left any votes out, or gotten any of the votes wrong, be sure
> >> to chime in!
> >>
> >> -Ted.
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Don Brown 
If we used the 'webwork' name in the package, I think we should abandon the idea of this being the second major version 
of Action.  In my opinion, a project needs to have a name, a single name, which one uses to identify it.  If we want to 
bring WebWork in as a new Struts subproject, and that is an option, then I'm fine with that.  However, I'm not OK with 
mixing webwork in with Action in with Struts.  We need to make a decision, then move on.


Don

Niall Pemberton wrote:

+1 to webwork - "org.apache.webwork" if thats allowed, otherwise
"org.apache.struts.webwork".

Niall

On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:

Hey there,

if webwork is an option as well, I would vote for org.apache.webwork :)

The tag prefix ui: won't be my choice... There are plenty of non-ui tags
within webwork. So this would result in something like: ui:/nonui: and
this would be quite annoying for me...
Same with html: prefix... Yes, some are html tags, but others are not...

So we would have to go the logic:, bean: and html: route...
Too much confusion...

Still my favourites are saf: or a: (and being sometimes lazy, ww: of
course :) )

cheers,
Rainer

PS: Can't we decide on this later if there is no consens now?
Since this is a simple refactoring with subversion it should not hold up
the incubation process for now...


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

+1

I would also be +1 to:
  - com.opensymphony.webwork package -> org.apache.struts.webwork or
org.apache.webwork
  - ww: tag prefix -> ui:



--
James Mitchell




On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:


STATUS so far

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

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

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

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

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

-Ted.

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



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




-
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: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Niall Pemberton 
On 3/27/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 3/27/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> >
> > Sorry for the late vote - my vote is for "alpha" quality as well, mainly
> > for
> > the same "standalone tiles is not released" reason cited by others, but
> > also
> > because of the way Commons Validator has been implemented. It appears that
> > the implementation was done based on an old version of validator where the
> > javascript was embedded in the XML config file. This means that 1)
> > maintenance of that javascript is the responsibility of Shale and 2)
> > upgrading to later versions of validator (such as the 1.3.0 version just
> > released) won't pick up bugfixes in the javascript as users would expect.
> > Is
> > there any objection to changing Shale to use the javascript from Commons
> > Validator?
>
>
> +1 ... could you file an RFE so we can implement this and track it for the
> release notes on the next version?

OK Done:

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

I'll try to get round to doing this in the next week or two, unless
someone beats me to it.

Niall

> (I also plan on reviewing the other dependencies ... for example, MyFaces
> should be shipping 1.1.2 any day now, and it has a fix for the bug that
> prevents SQL Browser from actually displaying data.)
>
> Niall
>
>
> Craig
>
> - Original Message -
> > From: "Wendy Smoak" <[EMAIL PROTECTED]>
> > Sent: Monday, March 27, 2006 6:13 AM
> >
> >
> > The vote results are as follows:
> >
> > Binding PMC Member votes:
> >Wendy Smoak - Alpha
> >Gary VanMatre - Alpha
> >Craig McClanahan - Alpha
> >
> > Non-binding:
> >Sean Schofield - Alpha
> >
> > Therefore, Shale 1.0.2 is designated as "Alpha" quality.
> >
> > Craig, as far as I can tell, there was never an announcement for Shale
> > 1.0.0, and it isn't in www.apache.org/dist/struts.  What would you
> > like to see happen with this one?
> >
> > At this point, my only distribution plans are to put the test
> > framework jar on ibiblio (via www.apache.org/dist/maven-repository) so
> > that MyFaces can use it for their release.
> >
> > Thanks,
> > --
> > Wendy

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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Ted Husted 
On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> PS: Can't we decide on this later if there is no consens now?
> Since this is a simple refactoring with subversion it should not hold up
> the incubation process for now...

+1

We can keep collecting input and decide sometime between now and the release :)

The critical task now is clearing the IP, so that we can distribute
the product free and clear under the Apache License.

-Ted.

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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Niall Pemberton 
+1 to webwork - "org.apache.webwork" if thats allowed, otherwise
"org.apache.struts.webwork".

Niall

On 3/27/06, Rainer Hermanns <[EMAIL PROTECTED]> wrote:
> Hey there,
>
> if webwork is an option as well, I would vote for org.apache.webwork :)
>
> The tag prefix ui: won't be my choice... There are plenty of non-ui tags
> within webwork. So this would result in something like: ui:/nonui: and
> this would be quite annoying for me...
> Same with html: prefix... Yes, some are html tags, but others are not...
>
> So we would have to go the logic:, bean: and html: route...
> Too much confusion...
>
> Still my favourites are saf: or a: (and being sometimes lazy, ww: of
> course :) )
>
> cheers,
> Rainer
>
> PS: Can't we decide on this later if there is no consens now?
> Since this is a simple refactoring with subversion it should not hold up
> the incubation process for now...
>
> >>  - com.opensymphony.webwork package -> org.apache.struts.action2
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:/saf:
> >
> > +1
> >
> > I would also be +1 to:
> >   - com.opensymphony.webwork package -> org.apache.struts.webwork or
> > org.apache.webwork
> >   - ww: tag prefix -> ui:
> >
> >
> >
> > --
> > James Mitchell
> >
> >
> >
> >
> > On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
> >
> >> STATUS so far
> >>
> >>  - com.opensymphony.webwork package -> org.apache.struts.ti
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:
> >>
> >> +1 Don Brown, Martin Cooper (binding)
> >> +1 Frank Zammetti  (non-binding)
> >>
> >>  - com.opensymphony.webwork package -> org.apache.struts.action2
> >>  - WebWork* classes -> Struts*
> >>  - WebWork in comments, documentation -> Struts Action 2
> >>  - webwork. as the configuration properties prefix -> struts.
> >>  - ww: tag prefix -> a:/saf:
> >>
> >> +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
> >> (binding)
> >> +0 Toby Jee, Hubert Rabago (binding)
> >> +1 Paul Benedict (non-binding)
> >>
> >> If I've left any votes out, or gotten any of the votes wrong, be sure
> >> to chime in!
> >>
> >> -Ted.
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> 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 39123] - [shale] Helper method for adding response headers and values

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




-- 
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 39123] New: - [shale] Helper method for adding response headers and values

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

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

   Summary: [shale] Helper method for adding response headers and
values
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


When using Shale Remoting, it is often necessary for the handler to add HTTP
headers to the response.  A utility method somewhere that abstracts away the
differences between the Servlet and Portlet APIs would be helpful.

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

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

Re: WebWork renaming strategy *revised*

2006-03-27 Thread Rainer Hermanns 
Hey there,

if webwork is an option as well, I would vote for org.apache.webwork :)

The tag prefix ui: won't be my choice... There are plenty of non-ui tags
within webwork. So this would result in something like: ui:/nonui: and
this would be quite annoying for me...
Same with html: prefix... Yes, some are html tags, but others are not...

So we would have to go the logic:, bean: and html: route...
Too much confusion...

Still my favourites are saf: or a: (and being sometimes lazy, ww: of
course :) )

cheers,
Rainer

PS: Can't we decide on this later if there is no consens now?
Since this is a simple refactoring with subversion it should not hold up
the incubation process for now...

>>  - com.opensymphony.webwork package -> org.apache.struts.action2
>>  - WebWork* classes -> Struts*
>>  - WebWork in comments, documentation -> Struts Action 2
>>  - webwork. as the configuration properties prefix -> struts.
>>  - ww: tag prefix -> a:/saf:
>
> +1
>
> I would also be +1 to:
>   - com.opensymphony.webwork package -> org.apache.struts.webwork or
> org.apache.webwork
>   - ww: tag prefix -> ui:
>
>
>
> --
> James Mitchell
>
>
>
>
> On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:
>
>> STATUS so far
>>
>>  - com.opensymphony.webwork package -> org.apache.struts.ti
>>  - WebWork* classes -> Struts*
>>  - WebWork in comments, documentation -> Struts Action 2
>>  - webwork. as the configuration properties prefix -> struts.
>>  - ww: tag prefix -> a:
>>
>> +1 Don Brown, Martin Cooper (binding)
>> +1 Frank Zammetti  (non-binding)
>>
>>  - com.opensymphony.webwork package -> org.apache.struts.action2
>>  - WebWork* classes -> Struts*
>>  - WebWork in comments, documentation -> Struts Action 2
>>  - webwork. as the configuration properties prefix -> struts.
>>  - ww: tag prefix -> a:/saf:
>>
>> +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen
>> (binding)
>> +0 Toby Jee, Hubert Rabago (binding)
>> +1 Paul Benedict (non-binding)
>>
>> If I've left any votes out, or gotten any of the votes wrong, be sure
>> to chime in!
>>
>> -Ted.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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

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

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

   Summary: [Shale] Implement use of Commons Validator Javascript
   Product: Struts
   Version: 1.0.2 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Currently shale uses javascript validation embedded in Shale's version of the 
XML config file rather than the standard Commons Validator javascript routines.
 
This has the consequence that the javascript has to be maintained by Shale, 
rather than taking advantage of improvements made to Commons Validator and 
users who upgrade their version of Validator won't get the javascript 
improvements they would expect.

Dev list discussion:
http://www.mail-archive.com/dev%40struts.apache.org/msg19468.html

-- 
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: r389223 - /struts/site/trunk/xdocs/doap_Struts.rdf

2006-03-27 Thread jmitchell 
Author: jmitchell
Date: Mon Mar 27 10:51:47 2006
New Revision: 389223

URL: http://svn.apache.org/viewcvs?rev=389223&view=rev
Log:
Quick fix for name

Modified:
struts/site/trunk/xdocs/doap_Struts.rdf

Modified: struts/site/trunk/xdocs/doap_Struts.rdf
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/doap_Struts.rdf?rev=389223&r1=389222&r2=389223&view=diff
==
--- struts/site/trunk/xdocs/doap_Struts.rdf (original)
+++ struts/site/trunk/xdocs/doap_Struts.rdf Mon Mar 27 10:51:47 2006
@@ -16,7 +16,7 @@
   http://Struts.rdf.apache.org/";>
 2006-03-16
 http://usefulinc.com/doap/licenses/asl20"; />
-http://Struts
+Apache Struts
 http://struts.apache.org"; />
 http://struts.apache.org"; />
 Home of several MVC Web Frameworks



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

Re: [WebWork2] TODO

2006-03-27 Thread Ian Roughley 
This is a good followup to what Craig is saying.  I accidentally sent 
it to Joe

instead of this list - hopefully got it right this time :)


It's not a JS API, but WW does have something similar in the theme's for the
tags.

At the moment we have a dojo theme, but Ranier was going to introduce a
prototype/scripactulous theme.  Some on the users list didn't like to 
introduce

dojo into pages that only needed a date picker/WYSIWYG editor - and hence the
current implementation (I did add a dojo implementation, but at the current
version of dojo this is a little flaky).

We had a discussion a few months back, and agreed on certain standard 
components

that each theme should implement.  What we need to be carefull of, is ensuring
that each theme implementation covers this same functionality.  One case of
this is that the prototype currently does not offer events similar to 
dojo - so
it would need to be clearly documentated that you cannot easy move 
between these

themes.




Quoting Craig McClanahan <[EMAIL PROTECTED]>:


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


On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> I wonder if there's a way to generalize an "API" out of these so that
> we are less bound to an implementation.  Certainly, a date picker or
> rich text field which ultimately just ends up setting a value of  a
> single form field should be not too hard to generalize, although I
> haven't looked at all the models for integrating JS widgets into a
> page neatly.  I guess there are also issues of triggering the
> widgets, etc.

Generalize an API out of GUI widgets?

Where's Craig with the JSF plug when you need him?!? :-) LOL



Ask and ye shall receive :-)  [1]

Seriously, wrapping DOJO widgets (using whatever technology you like on the
server side) is a heck of a lot more fun than writing all that javascript
yourself, as long as the underlying widget does what you need.  I'm
currently playing with a JSF component wrapper for DOJO's rich text editing
capability.  Took about an hour to do the wrapping -- the only issues I've
got relate to the widget implementation itself (doesn't support scrollbars,
and problems hooking in to the Save and Cancel events where I want to).

I've also seen people try to generalize *all* DOJO widgets with a single JSP
tag API.  This is a lot more practical in JSP 2.0, where you can declare a
tag that takes arbitrary parameters.  But I worry about usability issues of
a single tag like this, because you effectively have a "mode" of operation
for every widget (which would each only recognize only a subset of the
overall set of attributes).  We have small examples of this sort of thing
all over the Struts tag library ... just for an example, try to explain to a
newbie what combination of attributes to use on an  tag[2] when
you want to pass parameters in.

Wrapping is good, but I've come to believe in "one tag (or equivalent for
your favorite technology) per use case" is better than "one size fits all".

Frank


Craig

[1]
http://blogs.sun.com/roller/page/edwingo?entry=component_authoring_for_creator
[2] http://struts.apache.org/struts-taglib/tlddoc/html/frame.html






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

Re: [WebWork2] TODO

2006-03-27 Thread Michael Jouravlev 
On 3/27/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 3/27/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > I suggest to analyze all tags and to deprecate everything that is
> > already supported in JSTL 1.0.
>
> The tags are listed here, Michael, if you'd lke to run through them.
>
> * http://wiki.opensymphony.com/display/WW/Tags
>
> The UI tags are quite a bit different that the Action 1 taglibs. Aside
> from generating markup, many also observe a stylesheet, giving them
> capabilities beyond what is offered with JSTL alone.

I did not quite get that. Do you mean CSS stylesheet? I started
reading the WebWork book, but then put it aside, shame on me. So I am
not versed in WebWork yet. Anyway, CSS support is not a problem in
SAF1 tags either.

> The UI tags are
> also value-stack aware, allowing expressions that are not supported by
> standard JSTL.

I see. Considering that ValueStack is just a tree-like object
containing beans, I would prefer a very small set of tags to
put/remove ValueStack to a certain scope, and then access its
properties using standard JSTL expressions, if this is possible. I
thought that OGNL expressions are evaluated on a whole page like
JSP2.0 expressions, not within specific tags only. I guess I was
wrong. Would be great if OGNL expressions could be used anywhere on a
page, so I had to use as few WW-specific tags as possible.

> The UI tags look and feel like ordinary JSP
> tags, under the covers, the markups is being created with FreeMarker
> templates. (See same reference.)

I hope that plain JSP is still an option. I will try to find time to
finish the book ;-) Thanks for the heads up.

Michael.

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

Re: [WebWork2] TODO

2006-03-27 Thread Craig McClanahan 
On 3/27/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 3/27/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > On 3/27/06, Gabe <[EMAIL PROTECTED]> wrote:
> > > for the tag prefix, I am actually thinking "html" might be best.
> > > While Struts Action 2 is supposed to be a "revolution" in order
> > > for us to keep the community behind it, we ought to make it
> > > seem as much of an "evolution" as possible. (Otherwise, why
> > > wouldn't a struts developer look at this as the opportunity to try
> > > something completely different?) Therefore, I think using html
> > > for the ww form tags etc would be ideal.
> >
> > I like "html" prefix especially if the taglib could be portable to,
> > say, SAF 1.3 or even to plain JSP environment.
>
> Noted.


As we all know, the prefix that is actually used is up to the individual
developer, but most of them tend to copy our examples :-).

If I were a Struts 1.x user, and saw the "html" prefix on SAF 2.x tags, I
would expect the functionality to be fundamentally similar.  If that's what
ends up happening, then this is a pretty good suggestion.  But I fear it
would be confusing if the tags are radically different (i.e. improved :-).

ISTR there was also an idea floating around some of the early discussions
that SAF 2.x might want to support the Struts 1.x tags as a "legacy"
library, similar in spirit to creating a compatibility layer to talk to
Struts 1.x action classes.  If that path was followed, it would make more
sense to keep "html" for this library and use something else for the new
one.

> I suggest to analyze all tags and to deprecate everything that is
> > already supported in JSTL 1.0. WW features that duplicate features of
> > JSTL 1.1 should be considered "half-deprecated" since a lot of people
> > still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
> > nah). JSP 2.0 has new features like resource messages support, SAF2
> > should promote using these more generic J2EE features instead of
> > proprietary tags and property files.
>
> The tags are listed here, Michael, if you'd lke to run through them.
>
> * http://wiki.opensymphony.com/display/WW/Tags
>
> The UI tags are quite a bit different that the Action 1 taglibs. Aside
> from generating markup, many also observe a stylesheet, giving them
> capabilities beyond what is offered with JSTL alone. The UI tags are
> also value-stack aware, allowing expressions that are not supported by
> standard JSTL. Though, I  understand that the UI tags are JSTL aware
> and be mixed-and-matched with JSTL tags, as needed.
>
>
> > SAF2 should also make clear what platform it targets. Stripes, for
> > example, uses Java5 specifically for annotations and other internal
> > niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
> > Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
> > better target and JSP pages are much cleaner, but there should be
> > compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.
>
> Webwork 2.2 targetrs JDK 1.4, and I would suggest we stay that course,
> since I believe it it what most of the committers, including myself,
> are using in production. The UI tags look and feel like ordinary JSP
> tags, under the covers, the markups is being created with FreeMarker
> templates. (See same reference.)
>
> Meanwhlie, some work is being done on Java 5 extensions. I believe
> Shale is doing the same.
>
> * http://wiki.opensymphony.com/display/WW/J2SE+5+Support


Shale's current annotations are described here[1] -- see subpackages
"managed", "register", and "view".  However, most of them are pretty
specific to JSF at the moment.

One thing I'd also like to look at is integrating XWork interceptor stacks
directly into Shale, at both the local (calling a particular action method)
and global (in the application controller filter, where you can currently
customize the "all requests" processing with Commons Chain) locations.  If
that works out, then it should be possible to use any XWork-based
annotations directly.

In another thread, there was talk about using a consistent approach to
> annotations between Shale, Action 2, and Stecks (Action 1 -
> http://www.realsolve.co.uk/site/strecks/).
>
> Though, I think ideas for new developmen tmight better be discussed
> once the codebase clears the Incubator.
>
> -Ted


Craig

[1]
http://struts.apache.org/struts-shale/shale-tiger/apidocs/overview-summary.html

Re: [WebWork2] TODO

2006-03-27 Thread Craig McClanahan 
On 3/27/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> > I wonder if there's a way to generalize an "API" out of these so that
> > we are less bound to an implementation.  Certainly, a date picker or
> > rich text field which ultimately just ends up setting a value of  a
> > single form field should be not too hard to generalize, although I
> > haven't looked at all the models for integrating JS widgets into a
> > page neatly.  I guess there are also issues of triggering the
> > widgets, etc.
>
> Generalize an API out of GUI widgets?
>
> Where's Craig with the JSF plug when you need him?!? :-) LOL


Ask and ye shall receive :-)  [1]

Seriously, wrapping DOJO widgets (using whatever technology you like on the
server side) is a heck of a lot more fun than writing all that javascript
yourself, as long as the underlying widget does what you need.  I'm
currently playing with a JSF component wrapper for DOJO's rich text editing
capability.  Took about an hour to do the wrapping -- the only issues I've
got relate to the widget implementation itself (doesn't support scrollbars,
and problems hooking in to the Save and Cancel events where I want to).

I've also seen people try to generalize *all* DOJO widgets with a single JSP
tag API.  This is a lot more practical in JSP 2.0, where you can declare a
tag that takes arbitrary parameters.  But I worry about usability issues of
a single tag like this, because you effectively have a "mode" of operation
for every widget (which would each only recognize only a subset of the
overall set of attributes).  We have small examples of this sort of thing
all over the Struts tag library ... just for an example, try to explain to a
newbie what combination of attributes to use on an  tag[2] when
you want to pass parameters in.

Wrapping is good, but I've come to believe in "one tag (or equivalent for
your favorite technology) per use case" is better than "one size fits all".

Frank


Craig

[1]
http://blogs.sun.com/roller/page/edwingo?entry=component_authoring_for_creator
[2] http://struts.apache.org/struts-taglib/tlddoc/html/frame.html

Re: WebWork renaming strategy *revised*

2006-03-27 Thread James Mitchell 

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


+1

I would also be +1 to:
 - com.opensymphony.webwork package -> org.apache.struts.webwork or  
org.apache.webwork

 - ww: tag prefix -> ui:



--
James Mitchell




On Mar 25, 2006, at 5:27 PM, Ted Husted wrote:


STATUS so far

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

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

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

+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen  
(binding)

+0 Toby Jee, Hubert Rabago (binding)
+1 Paul Benedict (non-binding)

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

-Ted.

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




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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 09:45:15 2006
New Revision: 389207

URL: http://svn.apache.org/viewcvs?rev=389207&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=389207&r1=389206&r2=389207&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 09:45:15 2006
@@ -69,7 +69,7 @@
  - com.opensymphony.webwork package -> org.apache.web
  - WebWork in comments, documentation -> Struts Action 2
  - webwork. as the configuration properties prefix -> web
- - ww: tag prefix -> html:
+ - ww: tag prefix -> html: (Michael Jouravlev = +1 for html)
 
 +0 Joe Germuska, Ted Husted (binding) (both would not object to 
org.apache.webwork)
 +1 Gabed (non-binding)



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

Re: [WebWork2] TODO

2006-03-27 Thread Ted Husted 
On 3/27/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> On 3/27/06, Gabe <[EMAIL PROTECTED]> wrote:
> > for the tag prefix, I am actually thinking "html" might be best.
> > While Struts Action 2 is supposed to be a "revolution" in order
> > for us to keep the community behind it, we ought to make it
> > seem as much of an "evolution" as possible. (Otherwise, why
> > wouldn't a struts developer look at this as the opportunity to try
> > something completely different?) Therefore, I think using html
> > for the ww form tags etc would be ideal.
>
> I like "html" prefix especially if the taglib could be portable to,
> say, SAF 1.3 or even to plain JSP environment.

Noted.

> I suggest to analyze all tags and to deprecate everything that is
> already supported in JSTL 1.0. WW features that duplicate features of
> JSTL 1.1 should be considered "half-deprecated" since a lot of people
> still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
> nah). JSP 2.0 has new features like resource messages support, SAF2
> should promote using these more generic J2EE features instead of
> proprietary tags and property files.

The tags are listed here, Michael, if you'd lke to run through them.

* http://wiki.opensymphony.com/display/WW/Tags

The UI tags are quite a bit different that the Action 1 taglibs. Aside
from generating markup, many also observe a stylesheet, giving them
capabilities beyond what is offered with JSTL alone. The UI tags are
also value-stack aware, allowing expressions that are not supported by
standard JSTL. Though, I  understand that the UI tags are JSTL aware
and be mixed-and-matched with JSTL tags, as needed.


> SAF2 should also make clear what platform it targets. Stripes, for
> example, uses Java5 specifically for annotations and other internal
> niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
> Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
> better target and JSP pages are much cleaner, but there should be
> compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.

Webwork 2.2 targetrs JDK 1.4, and I would suggest we stay that course,
since I believe it it what most of the committers, including myself,
are using in production. The UI tags look and feel like ordinary JSP
tags, under the covers, the markups is being created with FreeMarker
templates. (See same reference.)

Meanwhlie, some work is being done on Java 5 extensions. I believe
Shale is doing the same.

* http://wiki.opensymphony.com/display/WW/J2SE+5+Support

In another thread, there was talk about using a consistent approach to
annotations between Shale, Action 2, and Stecks (Action 1 -
http://www.realsolve.co.uk/site/strecks/).

Though, I think ideas for new developmen tmight better be discussed
once the codebase clears the Incubator.

-Ted

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

Re: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Craig McClanahan 
On 3/27/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> Sorry for the late vote - my vote is for "alpha" quality as well, mainly
> for
> the same "standalone tiles is not released" reason cited by others, but
> also
> because of the way Commons Validator has been implemented. It appears that
> the implementation was done based on an old version of validator where the
> javascript was embedded in the XML config file. This means that 1)
> maintenance of that javascript is the responsibility of Shale and 2)
> upgrading to later versions of validator (such as the 1.3.0 version just
> released) won't pick up bugfixes in the javascript as users would expect.
> Is
> there any objection to changing Shale to use the javascript from Commons
> Validator?


+1 ... could you file an RFE so we can implement this and track it for the
release notes on the next version?

(I also plan on reviewing the other dependencies ... for example, MyFaces
should be shipping 1.1.2 any day now, and it has a fix for the bug that
prevents SQL Browser from actually displaying data.)

Niall


Craig

- Original Message -
> From: "Wendy Smoak" <[EMAIL PROTECTED]>
> Sent: Monday, March 27, 2006 6:13 AM
>
>
> The vote results are as follows:
>
> Binding PMC Member votes:
>Wendy Smoak - Alpha
>Gary VanMatre - Alpha
>Craig McClanahan - Alpha
>
> Non-binding:
>Sean Schofield - Alpha
>
> Therefore, Shale 1.0.2 is designated as "Alpha" quality.
>
> Craig, as far as I can tell, there was never an announcement for Shale
> 1.0.0, and it isn't in www.apache.org/dist/struts.  What would you
> like to see happen with this one?
>
> At this point, my only distribution plans are to put the test
> framework jar on ibiblio (via www.apache.org/dist/maven-repository) so
> that MyFaces can use it for their release.
>
> Thanks,
> --
> Wendy
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

2006-03-27 Thread Craig McClanahan 
On 3/27/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
>
> I've noticed that both DefinitionsFactory and ComponentDefinitions are
> both too (IMHO) tightly bound to the Locale.
> What I mean is that maybe using Locale class to distinguish between
> different sets of definitions is not a good idea. From my point of view,
> I think that where you are using Locale maybe it should be used a simple
> Object.
> This way you leave to the implementation what's the use of that "Locale"
> In the Struts-Tiles version there is the concept of "key" in the
> FactorySet.createDefinitionsFactory, that is a simple Object. I use it
> to do my own way to localize definitions.
> In other words, don't you think that "Locale" in those interfaces should
> be Objects?
> Ciao
> Antonio


One of the reasons I think using a Locale is a good choice is that you'll
need one later on anyway ... to generate Locale-sensitive date formats, for
example.  It is also the mechanism used universally throughout Java for this
kind of decision.  Finally, Struts already keeps track of the current Locale
for a user in a session variable, so it's easy to grab when you need it.
(JSF and other frameworks do the same sort of thing too.)

Craig

Re: [WebWork2] TODO

2006-03-27 Thread Michael Jouravlev 
On 3/27/06, Gabe <[EMAIL PROTECTED]> wrote:
> for the tag prefix, I am actually thinking "html" might be best.
> While Struts Action 2 is supposed to be a "revolution" in order
> for us to keep the community behind it, we ought to make it
> seem as much of an "evolution" as possible. (Otherwise, why
> wouldn't a struts developer look at this as the opportunity to try
> something completely different?) Therefore, I think using html
> for the ww form tags etc would be ideal.

I like "html" prefix especially if the taglib could be portable to,
say, SAF 1.3 or even to plain JSP environment.

I suggest to analyze all tags and to deprecate everything that is
already supported in JSTL 1.0. WW features that duplicate features of
JSTL 1.1 should be considered "half-deprecated" since a lot of people
still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
nah). JSP 2.0 has new features like resource messages support, SAF2
should promote using these more generic J2EE features instead of
proprietary tags and property files.

SAF2 should also make clear what platform it targets. Stripes, for
example, uses Java5 specifically for annotations and other internal
niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
better target and JSP pages are much cleaner, but there should be
compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.

On 3/27/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 7:39 AM -0500 3/27/06, Ted Husted wrote:
> >tabbedpane.vm Archived UI template
> >* Is this a server-side compoonent, or is there a Dojo equivalent?
>
> I'm not sure what this is -- is it this?
> http://archive.dojotoolkit.org/nightly/tests/widget/test_TabPane.html
>
> I've used Dojo tabs in an application satisfactorily.  A
> rearchitecture of the implementation introduced some problems, so I
> forked the original implementation into my own widget package and
> soldiered on.  I'm not enough of a JS/DHTML whiz to understand why my
> page looked wrong in the new tab implementation, but it was an
> awfully complicated page.

Would be great to see an example of how tabbed panes work with forms
and buttons inside the panels.

Michael.

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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 09:04:17 2006
New Revision: 389198

URL: http://svn.apache.org/viewcvs?rev=389198&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=389198&r1=389197&r2=389198&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 09:04:17 2006
@@ -20,7 +20,8 @@
 * There may also be a Dojo equivalent
 
 FCKEditor for the Richtexteditor tag
-* Is there a Dojo equivalent?
+* Toby will contact author about license change
+* There may also be a Dojo equivalent
 
 Walter Zorns tooltip library for all UI Tags
 * Is there a Dojo equivalent?



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

Re: [WebWork2] TODO

2006-03-27 Thread tm jee 
Hi Ted & Friends, 

I could contact the author of FCKEditor and Walter Zorns tooltip library about 
a license change or possible dual licensing. Will post back when I got any 
information.

rgds

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?

tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?



DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS

Has "Open Symphony Group" filed a software grant?

Has "ePlus Corporation" filed a software grant or CCLA for Jason?



NAMING CONVENTIONS

Option 1:

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

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

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

+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)

Option 3:
 - com.opensymphony.webwork package -> org.apache.web or .webwork
 - WebWork in comments, documentation -> Struts Action 2
 - webwork. as the configuration properties prefix -> web or webwork
 - else, remains the same

+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)



MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")

+1 Gabe



At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.

-Ted.

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




-
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo.

Re: [WebWork2] TODO

2006-03-27 Thread Joe Germuska 

At 9:59 AM -0500 3/27/06, Frank W. Zammetti wrote:

On Mon, March 27, 2006 9:22 am, Joe Germuska said:

 I wonder if there's a way to generalize an "API" out of these so that
 we are less bound to an implementation.  Certainly, a date picker or
 rich text field which ultimately just ends up setting a value of  a
 single form field should be not too hard to generalize, although I
 haven't looked at all the models for integrating JS widgets into a
 page neatly.  I guess there are also issues of triggering the
 widgets, etc.


Generalize an API out of GUI widgets?

Where's Craig with the JSF plug when you need him?!? :-) LOL


:)

But what I'm talking about here is a JavaScript API -- basically 
something that manages the discovery process for a widget 
implementation, like JAXP does for XML parsing and transformation.


maybe i'll float this question on the Dojo list...

Joe

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


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

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

Re: [WebWork2] TODO

2006-03-27 Thread Frank W. Zammetti 
On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> I wonder if there's a way to generalize an "API" out of these so that
> we are less bound to an implementation.  Certainly, a date picker or
> rich text field which ultimately just ends up setting a value of  a
> single form field should be not too hard to generalize, although I
> haven't looked at all the models for integrating JS widgets into a
> page neatly.  I guess there are also issues of triggering the
> widgets, etc.

Generalize an API out of GUI widgets?

Where's Craig with the JSF plug when you need him?!? :-) LOL

Frank

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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 06:41:41 2006
New Revision: 389158

URL: http://svn.apache.org/viewcvs?rev=389158&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=389158&r1=389157&r2=389158&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 06:41:41 2006
@@ -65,13 +65,21 @@
 +1 Paul Benedict, Michael Jouravlev (non-binding)
 
 Option 3:
- - com.opensymphony.webwork package -> org.apache.web or .webwork
+ - com.opensymphony.webwork package -> org.apache.web
  - WebWork in comments, documentation -> Struts Action 2
- - webwork. as the configuration properties prefix -> web or webwork
- - else, remains the same
+ - webwork. as the configuration properties prefix -> web
+ - ww: tag prefix -> html:
+
++0 Joe Germuska, Ted Husted (binding) (both would not object to 
org.apache.webwork)
++1 Gabed (non-binding)
+
+Option 4:
+ - com.opensymphony.webwork package -> org.apache.webwork
+ - WebWork in comments, documentation -> Struts Action 2
+ - else, same as o.c.webwork
+
++1 Scud (non-binding)
 
-+0 Joe Germuska, Ted Husted (binding)
-+1 Gabe, Scud (non-binding)
 
 
 



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

Re: [WebWork2] TODO

2006-03-27 Thread Joe Germuska 

At 7:39 AM -0500 3/27/06, Ted Husted 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


Dojo has a date picker:
http://archive.dojotoolkit.org/nightly/tests/widget/test_DatePicker.html

it is somewhat less fully featured than JSCalendar.  I haven't used 
it in an app.  JSCalendar has worked well for me in other apps, but I 
haven't gotten very deeply into how it works nor have I investigated 
integrating it with JSP tags.



FCKEditor for the Richtexteditor tag
* Is there a Dojo equivalent?


Dojo does have a rich text editor:
http://dojotoolkit.org/docs/rich_text.html
http://blog.dojotoolkit.org/2005/11/07/new-editor-widget-explained
http://archive.dojotoolkit.org/nightly/tests/widget/test_Editor.html

I've actually not yet had cause to apply a RTE in an application.


Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?


I'm pretty sure there is not.


tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?


I'm not sure what this is -- is it this?
http://archive.dojotoolkit.org/nightly/tests/widget/test_TabPane.html

I've used Dojo tabs in an application satisfactorily.  A 
rearchitecture of the implementation introduced some problems, so I 
forked the original implementation into my own widget package and 
soldiered on.  I'm not enough of a JS/DHTML whiz to understand why my 
page looked wrong in the new tab implementation, but it was an 
awfully complicated page.


I wonder if there's a way to generalize an "API" out of these so that 
we are less bound to an implementation.  Certainly, a date picker or 
rich text field which ultimately just ends up setting a value of  a 
single form field should be not too hard to generalize, although I 
haven't looked at all the models for integrating JS widgets into a 
page neatly.  I guess there are also issues of triggering the 
widgets, etc.


Hope this helps.
Joe

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


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

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

Re: [WebWork2] TODO

2006-03-27 Thread Gabe 

Ted,

What you have written below is not what I have suggested. I suggested:
 - com.opensymphony.webwork package -> org.apache.struts.web 
 - WebWork* classes -> Web*
 - WebWork in comments, documentation -> Struts Action 2
 - webwork. as the configuration properties prefix -> struts.
 - ww: tag prefix -> web

However, personally for the tag prefix, I am actually thinking "html" might be 
best. While Struts Action 2 is supposed to be a "revolution" in order for us to 
keep the community behind it, we ought to make it seem as much of an 
"evolution" as possible. (Otherwise, why wouldn't a struts developer look at 
this as the opportunity to try something completely different?) Therefore, I 
think using html for the ww form tags etc would be ideal.

I am not for naming that would keep webwork in any of the class names / file 
names.

Thanks,
Gabe

- Original Message 
From: Ted Husted <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, March 27, 2006 7:39:15 AM
Subject: Re: [WebWork2] TODO

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?

tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?



DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS

Has "Open Symphony Group" filed a software grant?

Has "ePlus Corporation" filed a software grant or CCLA for Jason?



NAMING CONVENTIONS

Option 1:

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

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

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

+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)

Option 3:
 - com.opensymphony.webwork package -> org.apache.web or .webwork
 - WebWork in comments, documentation -> Struts Action 2
 - webwork. as the configuration properties prefix -> web or webwork
 - else, remains the same

+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)



MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")

+1 Gabe



At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.

-Ted.

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





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

Re: [WebWork2] TODO

2006-03-27 Thread Ian Roughley 


I thought there was some talk of depreciating the tabbedpane (as 
opposed to the

tabbedpannel - ajax component). Pat - do you remember anything about this?

/Ian



Quoting Ted Husted <[EMAIL PROTECTED]>:


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?

tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?



DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS

Has "Open Symphony Group" filed a software grant?

Has "ePlus Corporation" filed a software grant or CCLA for Jason?



NAMING CONVENTIONS

Option 1:

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

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

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

+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)

Option 3:
- com.opensymphony.webwork package -> org.apache.web or .webwork
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> web or webwork
- else, remains the same

+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)



MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")

+1 Gabe



At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.

-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: r389131 - /incubator/webwork2/STATUS.txt

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 05:00:43 2006
New Revision: 389131

URL: http://svn.apache.org/viewcvs?rev=389131&view=rev
Log:
Add vote from the OS forum. 

Modified:
incubator/webwork2/STATUS.txt

Modified: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=389131&r1=389130&r2=389131&view=diff
==
--- incubator/webwork2/STATUS.txt (original)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 05:00:43 2006
@@ -71,7 +71,7 @@
  - else, remains the same
 
 +0 Joe Germuska, Ted Husted (binding)
-+1 Gabe (non-binding)
++1 Gabe, Scud (non-binding)
 
 
 



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

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

2006-03-27 Thread husted 
Author: husted
Date: Mon Mar 27 04:46:10 2006
New Revision: 389123

URL: http://svn.apache.org/viewcvs?rev=389123&view=rev
Log:
Initial check in of a STATUS file to track how we will clear incubator issues. 

Added:
incubator/webwork2/STATUS.txt   (with props)

Added: incubator/webwork2/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/STATUS.txt?rev=389123&view=auto
==
--- incubator/webwork2/STATUS.txt (added)
+++ incubator/webwork2/STATUS.txt Mon Mar 27 04:46:10 2006
@@ -0,0 +1,84 @@
+WEBWORK2 INCUBATION STATUS
+
+The current version of this file can be found at: 
+
+* http://svn.apache.org/viewcvs.cgi/incubator/webwork2/STATUS.txt
+
+This file supplements the formal incubator checkist at: 
+
+* http://incubator.apache.org/projects/webwork2.html
+
+As items are resolved here, they should be removed and noted on the formal 
checklist.
+
+
+
+
+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?
+
+tabbedpane.vm Archived UI template
+* Is this a server-side compoonent, or is there a Dojo equivalent?
+
+
+
+DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
+
+Has "Open Symphony Group" filed a software grant?
+
+Has "ePlus Corporation" filed a software grant or CCLA for Jason?
+
+
+
+NAMING CONVENTIONS
+
+Option 1:
+
+ - com.opensymphony.webwork package -> org.apache.struts.ti
+ - WebWork* classes -> Struts*
+ - WebWork in comments, documentation -> Struts Action 2
+ - webwork. as the configuration properties prefix -> struts.
+ - ww: tag prefix -> a:
+
++1 Martin Cooper (binding)
++0 Don Brown (binding)
++1 Frank Zammetti  (non-binding)
+
+Option 2:
+ - com.opensymphony.webwork package -> org.apache.struts.action2
+ - WebWork* classes -> Struts*
+ - WebWork in comments, documentation -> Struts Action 2
+ - webwork. as the configuration properties prefix -> struts.
+ - ww: tag prefix -> a:/saf:
+
++1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
+Brown (binding)
++0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
++1 Paul Benedict, Michael Jouravlev (non-binding)
+
+Option 3:
+ - com.opensymphony.webwork package -> org.apache.web or .webwork
+ - WebWork in comments, documentation -> Struts Action 2
+ - webwork. as the configuration properties prefix -> web or webwork
+ - else, remains the same
+
++0 Joe Germuska, Ted Husted (binding)
++1 Gabe (non-binding)
+
+
+
+MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
+
++1 Gabe
+
+
+
+

Propchange: incubator/webwork2/STATUS.txt
--
svn:eol-style = native



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

Re: [WebWork2] TODO

2006-03-27 Thread Ted Husted 
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?

tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?



DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS

Has "Open Symphony Group" filed a software grant?

Has "ePlus Corporation" filed a software grant or CCLA for Jason?



NAMING CONVENTIONS

Option 1:

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

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

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

+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)

Option 3:
 - com.opensymphony.webwork package -> org.apache.web or .webwork
 - WebWork in comments, documentation -> Struts Action 2
 - webwork. as the configuration properties prefix -> web or webwork
 - else, remains the same

+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)



MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")

+1 Gabe



At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.

-Ted.

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

Re: [VOTE] Struts Shale v1.0.2 Quality

2006-03-27 Thread Niall Pemberton 
Sorry for the late vote - my vote is for "alpha" quality as well, mainly for
the same "standalone tiles is not released" reason cited by others, but also
because of the way Commons Validator has been implemented. It appears that
the implementation was done based on an old version of validator where the
javascript was embedded in the XML config file. This means that 1)
maintenance of that javascript is the responsibility of Shale and 2)
upgrading to later versions of validator (such as the 1.3.0 version just
released) won't pick up bugfixes in the javascript as users would expect. Is
there any objection to changing Shale to use the javascript from Commons
Validator?

Niall

- Original Message - 
From: "Wendy Smoak" <[EMAIL PROTECTED]>
Sent: Monday, March 27, 2006 6:13 AM


The vote results are as follows:

Binding PMC Member votes:
   Wendy Smoak - Alpha
   Gary VanMatre - Alpha
   Craig McClanahan - Alpha

Non-binding:
   Sean Schofield - Alpha

Therefore, Shale 1.0.2 is designated as "Alpha" quality.

Craig, as far as I can tell, there was never an announcement for Shale
1.0.0, and it isn't in www.apache.org/dist/struts.  What would you
like to see happen with this one?

At this point, my only distribution plans are to put the test
framework jar on ibiblio (via www.apache.org/dist/maven-repository) so
that MyFaces can use it for their release.

Thanks,
--
Wendy




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

[Standalone Tiles] Maybe too much bound to Locale

2006-03-27 Thread Antonio Petrelli 
I've noticed that both DefinitionsFactory and ComponentDefinitions are 
both too (IMHO) tightly bound to the Locale.
What I mean is that maybe using Locale class to distinguish between 
different sets of definitions is not a good idea. From my point of view, 
I think that where you are using Locale maybe it should be used a simple 
Object.

This way you leave to the implementation what's the use of that "Locale"
In the Struts-Tiles version there is the concept of "key" in the 
FactorySet.createDefinitionsFactory, that is a simple Object. I use it 
to do my own way to localize definitions.
In other words, don't you think that "Locale" in those interfaces should 
be Objects?

Ciao
Antonio


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

Re: [WebWork2] TODO

2006-03-27 Thread Rene Gielen 

Ted, others,

I would volunteer to ask for license changes at least for jscalendar, 
but I can do the others as well - if there is no one around who has 
existing links to the said projects and / or their representatives 
making it easier to "get through" (which I do not have explicitely).


Regards,
Rene

Ted Husted schrieb:


The big item on the Incubator TODO list is verifying distribution
rights. The items here are

(1) Verify that the files that have been donated have been updated to
reflect the new ASF copyright.

(2) Verify that for all code included with the distribution that is
not under the Apache license, we have the right to combine with
Apache-licensed code and redistribute.

(3) Verify that all source code distributed by the project is covered
by one or more of the following approved licenses: Apache, BSD,
Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the
same terms.



As to (3), in another thread Rainer cited at least four components
that we need to be address

* JSCalendar for the DatePicker tag

* FCKEditor for the Richtexteditor tag

* Walter Zorns tooltip library for all UI Tags

* tabbedpane.vm Archived UI template

Martin suggested that there may be DOJO equivalents for all four of
these. (Unless tabbed pane is server-side.)

Is anyone planning on checking on these yet?



As to (2), if we resolve (3), will there be any other *code* that
would not be under the ASF.

As to (1), I scanned the Java source for copright statements. We seem
to be in pretty good shape. Most of those that have copyright
statements run to "Open Symphony Group". But, there are a few
exceptions.

* Copyright (c) 2005 ePlus Corporation (SessionContextAutowiringInterceptor)
* Copyright (C) NanoContainer Organization (org.apache.struts.action2.pico)
* Copyright (c) 2005 Your Corporation.

Well, the last one, I think we can safely ignore :)

I believe the first one is Jason's employer. If possible, it would be
great if we could get a software grant or CCLA to cover this class.

Meanwhile, has the software grant for "Open Symphony Group" gone on
file yet? I looked but I didn't see it.

-

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]

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

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-27 12:20 ---
I'm getting that exact same exception when invoking the login module (just
trying to access the login form causes the bug).

I'm using weblogic platform 8.1 sp5 with struts 1.2.4.

The login module is called via a web application's login.jsp. This JSP has a
form with action "j_security_check".

-- 
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()

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-27 12:17 ---
I'm getting that exact same exception when invoking the login module (just
trying to access the login form causes the 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]