Ted Husted wrote:
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer action-default.xml to struts-default.xml
is that we want people to be able to use Struts Action 1 and Struts
Action 2 in the
Bob this is really a great list for doing some house cleaning.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=52211#52211
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Bob Lee
Sent: Tuesday, April 18, 2006 9:56 PM
To: Struts Developers List; [EMAIL PROTECTED]
Subject: Re: XWork and Struts Action 2.0
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote:
I would tend
--- Pilgrim, Peter [EMAIL PROTECTED]
wrote:
As a new user of WebWork 2.2 I dont see much of
XWork except for the
xwork.xml file. So I agree totally. This is not to
say that as an
advanced user, one day I might decide to exploit an
XWork feature.
Actions itself, parameter setting /
I've added my comments inline...
As an aside, any chance of us getting Confluence set up? It's painful going
back to a regular wiki :-)
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
I'll set up the rough spots page.
http://wiki.apache.org/struts/RoughSpots?action=show
Bob
Carreira [EMAIL PROTECTED]
To: dev@struts.apache.org
Sent: Wednesday, April 19, 2006 11:38:10 AM
Subject: Re: XWork and Struts Action 2.0
I've added my comments inline...
As an aside, any chance of us getting Confluence set up? It's painful going
back to a regular wiki :-)
On 4/18/06, Bob Lee [EMAIL
OK, I read this whole thread and will provide my general comments here and my
specific comments about Bob's wiki entry on the wiki itself.
First, we need to recognize there are a few different proposals here:
1) Drop XW directly in to WW (ie: fork). This is Bob's proposal.
2) Move XW over to
Patrick Lightbody wrote:
We can definitely start by reading struts.xml rather than xwork.xml.
+1, works great with struts-default.xml
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer action-default.xml to struts-default.xml
is that we want people to be able to use Struts Action 1 and Struts
Action 2 in the same application
I vote for struts-action.xml.
Bob
On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote:
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer action-default.xml to struts-default.xml
is that we want
Bob Lee wrote:
I vote for struts-action.xml.
+1
Don
Bob
On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote:
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer action-default.xml to
+1 to your +1
--
James Mitchell
On Apr 19, 2006, at 3:10 PM, Don Brown wrote:
Bob Lee wrote:
I vote for struts-action.xml.
+1
Don
Bob
On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote:
We might want to keep a straight-line mapping in the naming
conventions, where
OpenSymphony -
+1 for struts-action.xml
Bob Lee wrote:
I vote for struts-action.xml.
Bob
On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote:
We might want to keep a straight-line mapping in the naming conventions, where
OpenSymphony - Apache Struts
WebWork - Action
A good reason to prefer
+1 for struts-action.xml
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=52352#52352
-
To unsubscribe, e-mail:
+1 struts-action.xml
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=52373#52373
-
To unsubscribe, e-mail: [EMAIL
On 4/19/06, Patrick Lightbody [EMAIL PROTECTED] wrote:
1) Drop XW directly in to WW (ie: fork). This is Bob's proposal.
Just to clarify what I already said on the wiki page, I propose that
we make XWork an implementation detail, not part of our API. This
means creating a thin abstraction layer
On 4/17/06, Gabe [EMAIL PROTECTED] wrote:
It's telling that the lion's share of code related issues we've discussed so
far about Struts
2 on this list (Annotation driven actions, pluggability of expression
language, use of dev
mode, etc., etc.) are really issues that should be brought to
Don Brown wrote:
Bob Lee wrote:
Also, how do the tags relate to JSTL? Are we just going to ignore
JSTL? Or are we going to use JSTL for JSP with some WebWork-specific
extensions and the WebWork tags for other template engines?
I personally prefer the latter option. Struts has always tried to
Ian Roughley wrote:
Don Brown wrote:
Bob Lee wrote:
Also, how do the tags relate to JSTL? Are we just going to ignore
JSTL? Or are we going to use JSTL for JSP with some WebWork-specific
extensions and the WebWork tags for other template engines?
I personally prefer the latter option.
This doesn't concern XWork itself.
Huh? I thought we were talking about moving it?
The question is can Struts continue to depend on
XWork externally and
actually be cohesive? I want one comprehensive
manual. I don't
necesarily want the servlet API to be readily
available, but when I
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote:
This doesn't concern XWork itself.
Huh? I thought we were talking about moving it?
I didn't say anything about moving it.
Okay, so make your Action implement ServletContextAware, ServletRequestAware,
etc.
I was specifically thinking
On 4/18/06, Jason Carreira
[EMAIL PROTECTED] wrote:
This doesn't concern XWork itself.
Huh? I thought we were talking about moving it?
I didn't say anything about moving it.
Ahh, you're talking about forking it and copying the source into Struts Action
2?
-(as many as I'm allowed
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote:
Ahh, you're talking about forking it and copying the source into Struts
Action 2?
No... but I do think we should shield Struts users from the XWork
API/documentation as much as possible (i.e. a lot more than WebWork
does). I _suppose_ it's
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
No... but I do think we should shield Struts users from the XWork
API/documentation as much as possible (i.e. a lot more than WebWork
does). I _suppose_ it's nice that you can drop down to XWork and do
non-web things, but I don't think we need to
Sent: Tuesday, April 18, 2006 3:24:06 PM
Subject: Re: XWork and Struts Action 2.0
I would tend to disagree. I feel that the separate of concerns between
XWork and a web application front end are important. I don't believe
it would be helpful to start lumping things back together again.
I would
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote:
I would tend to disagree. I feel that the separate of concerns between
XWork and a web application front end are important. I don't believe
it would be helpful to start lumping things back together again.
Providing Struts users with a complete,
This has been a topic I've been wondering about for a while: would it be possible to move to Java 5, then use a tool
such as Retroweaver [1] to provide Java 1.4 support? I'm not prepared to completely abandon Java 1.4 users, but Bob
does make some good points regarding the concern for falling
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
Without saying whether we should support 1.4 or not, realistically
we're talking about Struts 2.0.0 in production some time after August
depending how long it takes users to port their applications, not
right now, at this moment, right? JDK 1.6
You mean we have committers who aren't running 1.5 yet? For shame. ;)
I'll set up the rough spots page.
Bob
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote:
When a committer votes +1 on a release, it's taken to mean that the
committer is using the release in production his or herself, and that
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
I'll set up the rough spots page.
http://wiki.apache.org/struts/RoughSpots?action=show
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
This is a great list, thanks for taking the time to put it up. I may not agree with everything, but it is sure to spark
conversation :)
Don
Bob Lee wrote:
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote:
I'll set up the rough spots page.
http://wiki.apache.org/struts/RoughSpots?action=show
What's the plan for XWork? I would recommend against keeping it as a
third party dependency and for copying the necessary code over into
the Struts repository and refactoring it (clean up exception handling,
remove statics, better integrate APIs, etc.). We could keep the Java
packages separate (if
-1 to moving it over. XWork is not just part of WebWork, it's used other
places.
You're more than welcome to help do the cleanup in XWork for a 2.0 release.
-
Posted via Jive Forums
Whether XWork is moved to Apache or not, I 100% agree the docs and API should be in a single location. WebWork has been
doing this for a while, and I think we should continue the practice. The relationship between Action 2 and XWork could
be like Action 1 and Commons Validator - the user
This doesn't concern XWork itself.
The question is can Struts continue to depend on XWork externally and
actually be cohesive? I want one comprehensive manual. I don't
necesarily want the servlet API to be readily available, but when I
need it, I'd prefer not to go through a ThreadLocal. Having
Bob Lee wrote:
Also, how do the tags relate to JSTL? Are we just going to ignore
JSTL? Or are we going to use JSTL for JSP with some WebWork-specific
extensions and the WebWork tags for other template engines?
I personally prefer the latter option. Struts has always tried to work well with
this, i was told to get the XWork
developers involved, so I think I will go do that now. ;-)
Gabe
- Original Message
From: Jason Carreira [EMAIL PROTECTED]
To: dev@struts.apache.org
Sent: Monday, April 17, 2006 4:37:59 PM
Subject: Re: XWork and Struts Action 2.0
-1 to moving it over
37 matches
Mail list logo
