Author: husted
Date: Fri Oct 29 02:17:46 2004
New Revision: 55952
Added:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/
- copied from rev 55951,
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/impl/
Removed:
Author: husted
Date: Fri Oct 29 02:19:23 2004
New Revision: 55953
Added:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
- copied unchanged from rev 55952,
Author: husted
Date: Fri Oct 29 02:19:51 2004
New Revision: 55954
Added:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShaleConstants.java
- copied unchanged from rev 55953,
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ImplConstants.java
Author: husted
Date: Fri Oct 29 02:20:22 2004
New Revision: 55955
Added:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShalePhaseListener.java
- copied unchanged from rev 55954,
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ImplPhaseListener.java
Author: husted
Date: Fri Oct 29 02:20:50 2004
New Revision: 55956
Added:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShaleViewHandler.java
- copied unchanged from rev 55955,
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ImplViewHandler.java
Author: husted
Date: Fri Oct 29 02:42:31 2004
New Revision: 55959
Modified:
struts/trunk/contrib/struts-shale/src/conf/faces-config.xml
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
Author: husted
Date: Fri Oct 29 03:49:44 2004
New Revision: 55962
Modified:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/ViewController.java
Log:
Javadoc change only: Minor stylistic changes to help clarify how ViewController
integrates with the JSF lifecycle.
Modified:
Author: husted
Date: Fri Oct 29 03:51:10 2004
New Revision: 55963
Modified:
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/Constants.java
struts/trunk/contrib/struts-shale/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30876.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31684.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31790.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31827.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31852.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31890.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I started a Problem Issue Roadmap to prepare for a 1.2.6 milestone, but now that we've
started to break the MailReader database out into a separate package, perhaps we
should forge ahead and look towards 1.3.0.
Are we ready for the 1.3.0 plunge?
Problem Ticket Roundmap
* #5157 -
I would like to start pushing commons-resource for promotion so we can move
to it in the 1.3.x time frame. I have never been part of the promotion
process, but I am willing to do all the work. Does it make sense for me to
start this ball rolling?
--
James Mitchell
Software Engineer / Open
So, re we keeping this undeprecated for the sake of the ActionForm validate
signature, et al?
When we move to Commons Resources, are we planning to keep it as convenience subclass
(to preserve the API signature)?
-Ted.
-
To
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31922.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31960.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
At 9:19 AM -0400 10/29/04, Ted Husted wrote:
So, re we keeping this undeprecated for the sake of the ActionForm
validate signature, et al?
When we move to Commons Resources, are we planning to keep it as
convenience subclass (to preserve the API signature)?
Are we going to get out of
On Fri, 29 Oct 2004 08:35:11 -0500, Joe Germuska wrote:
This may be Ted's question asked in different words.
My question in different words :) is:
What is the roadmap for ActionMessage/ActionMessages and ActionError/ActionErrors for
1.3 and beyond?
The endgame has been to migrate to Commons
I wouldn't mind seeing commons-i18n rolled in as well, although I can't see
how fits in the generic sense.still noodling. That may be something I
should worry about at a later date.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
If you're a Commons Committer already, just add your name to the roster, and have at
it :)
Essentially, make sure that it would be ready for release, and then float a vote to
promote it.
Once it's promoted, we can roll a release and move the Struts 1.3.x dependencies (if
we are ready to
Author: husted
Date: Fri Oct 29 08:34:55 2004
New Revision: 55980
Modified:
struts/trunk/src/share/org/apache/struts/config/ForwardConfig.java
struts/trunk/src/share/org/apache/struts/taglib/html/LinkTag.java
Log:
Document that if a link to a forward is used to switch modules, the path must
ActionError has been deprecated for some time so we could remove it in
1.3. ActionErrors only exists because of ActionForm.validate(). I
figured we would remove ActionErrors, ActionMessages, and ActionMessage in
2.0 and replace them with commons-resources.
I wouldn't be opposed to deprecating
At 8:51 AM -0700 10/29/04, David Graham wrote:
ActionError has been deprecated for some time so we could remove it in
1.3. ActionErrors only exists because of ActionForm.validate(). I
figured we would remove ActionErrors, ActionMessages, and ActionMessage in
2.0 and replace them with
On Fri, 29 Oct 2004 11:31:34 -0500, Joe Germuska wrote:
Anyone have strong feelings about the method name? Obviously we
can't use validate.
Are we going to make any API additions in 1.3.x or 1.4.x?
For example, Validate includes a parameter for the ServletRequest. Are we going to
migrate
At 12:50 PM -0400 10/29/04, Ted Husted wrote:
On Fri, 29 Oct 2004 11:31:34 -0500, Joe Germuska wrote:
ÝAnyone have strong feelings about the method name? ÝObviously we
Ýcan't use validate.
Are we going to make any API additions in 1.3.x or 1.4.x?
For example, Validate includes a parameter for
the
--- Joe Germuska [EMAIL PROTECTED] wrote:
At 8:51 AM -0700 10/29/04, David Graham wrote:
ActionError has been deprecated for some time so we could remove it in
1.3. ActionErrors only exists because of ActionForm.validate(). I
figured we would remove ActionErrors, ActionMessages, and
All,
I am using Struts-faces Integration library 1.0. I recently came across the
problem using HttpServletRequestWrapper from it. It implements
HttpServletRequest class but per spec. servlet 2-4, all request wrapppers
should extend javax.servlet.http.HttpServletRequestWrapper class.
Here is
Have you looked at Rhino http://www.mozilla.org/rhino/ ? It lets you
access Java from JS and JS from Java so you might not need to handle types
if you just pass the JS into the Rhino interpreter.
I'm not sure I understand the use cases for your proposal though.
David
--- [EMAIL PROTECTED]
That's a good point. Start simply by making ActionContext have
bean properties for the four objects normally passed into execute?
Someone mentioned they were already using an ActionContext in their own apps. Was it
you, Joe?
Perhaps it should be based on the Chain Context, which has
I do have some experience with Rhino, I actually integrated it into DataVision a few
weeks ago for Javascript formula support (new release coming at some point!). I
hadn't considered it for this... I'll have to think about it a bit. Off the top of my
head it seems like it might be a little
Actually, I just wrote a web application that uses Struts 1.2.4, Struts
Flow - http://struts.sf.net/flow , iBATIS database layer, and a touch of
Java. Struts Flow allows you to use a Javascript function to replace a
Struts action. I use iBATIS to run SQL queries and return Lists of Maps
(a
Yep, I agree on the Map point, that's why I mentioned maybe just a
HashMap would suffice. I had some doubt only because I'm not familiar
yet with how the converter gets written (I just looked at the javadocs
for the first before I write that proposal, just to get a rough idea).
As for the
I didn't see anything in that proposal that couldn't be satisfied by
Struts Flow, but I could have missed something. If so, we could
supplement Struts Flow to support it. Converting Javascript objects to
Maps should be a sufficient way to handle compatibility with existing
Struts
Struts Flow allows you to use a Javascript function to replace a
Struts action. I use iBATIS to run SQL queries and return Lists of
Maps (a Map keyed by column names in the result set), then feed
those Maps to the JSP. Struts Flow provides a jsobjectToMap
function that lets you convert a
Don, Frank,
My understanding of the proposal is that its goal is to somehow
convert client-side javascript objects to server side java objects,
and my understanding of Struts flow is that it uses server side
scripting languages in place of precompiled java classes. Am I
correct on both counts?
I can only comment on my proposal as I don't know anything about Flow...
You are correct, the goal is converting client-side objects to
server-side ones (and vice-versa). Beyond that I can't really comment.
You are correct in that the client-side objects get serialized and then
submitted,
Hey all.
I was going to fix a small typo on the validation user guide page, and
can't get Eclipse/Subclipse to properly create a patch for me. Every
time I try to create the patch, the full path to my checked out version
is used in it, which seems wrong. I looked at a couple other patches in
Hmm...good question. :) Struts BSF is a very simple project that lets
you write a Struts action using a BSF-supported scripting language. The
advantage of this project is you can use any BSF-compatible language
including Python, Ruby, Groovy, Javascript, Perl and even VBScript (on
windows).
However, I think there is still some debate to be had
about whether such functionality makes sense in the core of Struts (I'm
starting to think not myself, but it's probably debatable).
Yes, this was my first reaction, too, that something like this
sounds like it /doesn't have to be//should
On Fri, 29 Oct 2004 13:12:39 -0700 (PDT), [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I do have some experience with Rhino, I actually integrated it into DataVision a few
weeks ago for Javascript formula support (new release coming at some point!). I
hadn't considered it for this... I'll have
Hey, I'll could do that this weekend, but I thought I was to wait until
1.2.5 was rolled, which has, well, stalled. Damn you and your dark,
velvety carrot. :)
Don
Ted Husted wrote:
On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote:
Struts Flow will be added to Struts soon as an official
That sounds great to me, Don. :)
We already have Struts-Faces and Struts-Examples on the trunk. We might as well add
Struts-BSF and Struts-Flow to the mix.
Struts-BSF and Struts-Flow are not part of the core, so they would be not affected by
a 1.2.x branch.
-Ted.
On Fri, 29 Oct 2004 14:59:18
Author: martinc
Date: Fri Oct 29 19:50:56 2004
New Revision: 56011
Added:
struts/trunk/src/share/org/apache/struts/actions/DownloadAction.java
Log:
New abstract action that provides the nuts and bolts for downloading files from a
Struts application.
Added:
Cool Martin, thanks! What about the sample app I put together? Is that
going to be included as well? I think it shows how to use
DownloadAction a couple of ways, should get the job done I think. It's
still out there for download if you need it
(http://www.omnytex.com/downloadapp.zip)
--
Argh, posted to the wrong list!
Well, in all honesty, this isn't something that was initiated by me,
I've never had a thought of passing objects back and forth, so I'm not
sure I can give you a real, concrete use case that would explain it. I
certainly hear what your saying about XML. I
Date: 2004-10-29T20:55:16
Editor: EddieBush [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: EddieBush
URL: http://wiki.apache.org/struts/EddieBush
no comment
Change Log:
--
@@ -19,6 +19,28 @@
*
Date: 2004-10-29T21:05:05
Editor: EddieBush [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: EddieBush
URL: http://wiki.apache.org/struts/EddieBush
no comment
Change Log:
--
@@ -23,23 +23,23 @@
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
Argh, posted to the wrong list!
Well, in all honesty, this isn't something that was initiated by me,
I've never had a thought of passing objects back and forth, so I'm not
sure I can give you a real, concrete use
Craig,
I've updated the docs, can you change the nightly build to include beanutils
1.7.0 and remove Collections please.
Thanks
Niall
- Original Message -
From: James Mitchell [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, October 26, 2004 4:16 PM
Shouldn't commons-collections.jar be removed from all our build.xml
files as well? That's what my nightly build executes.
Craig
On Sat, 30 Oct 2004 05:20:11 +0100, Niall Pemberton
[EMAIL PROTECTED] wrote:
Craig,
I've updated the docs, can you change the nightly build to include beanutils
I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ -
and have used it successfully in several projects, an ASP application
and a Struts-based application. I've heard of others, but that one
has been good to me as it works with IE 5.5+ and Mozilla 1.0+.
This also seems to be a
I need to look at those links in a little more detail... At a glance I'm
not sure they fulfill the same goal (although they look to be without a
doubt very cool!)... I need to evaluate them more though to be sure.
I agree 100% with your comment about remote scripting... I think there
was a big
http://jakarta.apache.org/site/decisions.html
^^ Link to Tomcat Procedures ^^
http://jakarta.apache.org/site/guidelines.html
^^ Overall Tomcat Guidelines ^^
I updated the releases documentation to point to the Tomcat Procedures.
AFAICT the remainder of the release notes look good. Feel free to
56 matches
Mail list logo
