Re: XWork and Struts Action 2.0
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 same application space. We already have a "struts-config.xml". While these file names don't actually conflict, it might be clearer to name the new configurations "action" rather than "struts" to avoid confusion. So, I would suggest that we use "action-default.xml", and any place where we've started to say "struts", we might consider saying "action", so as to avoid confusion and conflict with Struts Action 1. +1 struts-action.xml -- Peter Pilgrim ( Windows XP / Thunderbird 1.5 ) __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 which Struts users will use. Users' code will have no direct depedencies on XWork. Our implementation (custom tags, interceptors, etc.) can continue to use the XWork API so long as we don't expose it to the user. It's important to get the API right now. We can always go back and clean up the implementation later. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
+1 struts-action.xml - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=52373#52373 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
+1 for struts-action.xml - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=52352#52352 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
+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 "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 space. We already have a "struts-config.xml". While these file names don't actually conflict, it might be clearer to name the new configurations "action" rather than "struts" to avoid confusion. So, I would suggest that we use "action-default.xml", and any place where we've started to say "struts", we might consider saying "action", so as to avoid confusion and conflict with Struts Action 1. -Ted. On 4/19/06, Don Brown <[EMAIL PROTECTED]> wrote: 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 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: XWork and Struts Action 2.0
+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 -> 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 space. We already have a "struts-config.xml". While these file names don't actually conflict, it might be clearer to name the new configurations "action" rather than "struts" to avoid confusion. So, I would suggest that we use "action-default.xml", and any place where we've started to say "struts", we might consider saying "action", so as to avoid confusion and conflict with Struts Action 1. -Ted. On 4/19/06, Don Brown <[EMAIL PROTECTED]> wrote: 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 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: XWork and Struts Action 2.0
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 "struts-default.xml" is that we want people to be able to use Struts Action 1 and Struts Action 2 in the same application space. We already have a "struts-config.xml". While these file names don't actually conflict, it might be clearer to name the new configurations "action" rather than "struts" to avoid confusion. So, I would suggest that we use "action-default.xml", and any place where we've started to say "struts", we might consider saying "action", so as to avoid confusion and conflict with Struts Action 1. -Ted. On 4/19/06, Don Brown <[EMAIL PROTECTED]> wrote: 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 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: XWork and Struts Action 2.0
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 people to be able to use Struts Action 1 and Struts > Action 2 in the same application space. We already have a > "struts-config.xml". While these file names don't actually conflict, > it might be clearer to name the new configurations "action" rather > than "struts" to avoid confusion. > > So, I would suggest that we use "action-default.xml", and any place > where we've started to say "struts", we might consider saying > "action", so as to avoid confusion and conflict with Struts Action 1. > > -Ted. > > On 4/19/06, Don Brown <[EMAIL PROTECTED]> wrote: > > 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 PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 space. We already have a "struts-config.xml". While these file names don't actually conflict, it might be clearer to name the new configurations "action" rather than "struts" to avoid confusion. So, I would suggest that we use "action-default.xml", and any place where we've started to say "struts", we might consider saying "action", so as to avoid confusion and conflict with Struts Action 1. -Ted. On 4/19/06, Don Brown <[EMAIL PROTECTED]> wrote: > 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 PROTECTED]
Re: XWork and Struts Action 2.0
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 PROTECTED]
Re: XWork and Struts Action 2.0
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 Struts. This is Gabe's proposal. 3) Leave XW where it is. This is Jason's proposal. For all intents and purposes, I think that we're going to have to live with #3 for some time. This does not, however, preclude us from doing some major overhauls (many of which Bob has suggested) in XW. And the time to do them would be now (as in immediately, as in the second we agree on the changes), so that we can get them addressed before SAF 2.0. As for the general confusion about XW and WW, we purposely called everything "WebWork" (except in the chapter discussing XW) for the very reason that WebWork/Struts users just don't care about XW. Getting XW out of their face should be an important goal. We can definitely start by reading "struts.xml" rather than "xwork.xml". I think for now we should leave this discussion alone and instead focus on what needs to happen to WebWork and XW to get it ready for SAF 2.0. Now I'm going to comment on the wiki :) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=52293#52293 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 PROTECTED]> wrote: > > I'll set up the "rough spots" page. > > http://wiki.apache.org/struts/RoughSpots?action=show > > Bob - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=52269#52269 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XWork and Struts Action 2.0
--- "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 / convesion, validation, dependency injection are all coming from xwork ;) good news is that most of there features is not touching your source code. regards, [ Konstantin Pribluda http://www.pribluda.de ] Still using XDoclet 1.x? XDoclet 2 is released and of production quality. check it out: http://xdoclet.codehaus.org __ 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]
RE: XWork and Struts Action 2.0
> -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 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, cohesive API doesn't preclude > this separation. > > > I do think one problem is that our approach to referring to XWork in > > the WW book and documentation is inconsistent. There is a > tendency to > > refer to everything as WebWork when it is not. Moving > forward, I think > > we simply need to be more carefult to say XWork when we > mean XWork and > > SAF when we mean SAF, and perhaps just refer to "the framework" when > > we do not care to make the distinction. > > This is exactly what I'm talking about. 99.9% of users (100% of Struts > users) don't care about this separation, and they have trouble with > it. Even the authors have trouble keeping it straight. > 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. > > No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some > > future release will increment the platform, but right now, most > > everyone I know is using Java 1.4 in production. Action 2.0 is meant > > to be something that we can all start using in production now. > > 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 comes out in the fall at > which point 1.4 will be two major releases behind. We must embrace > 1.5. We should keep in mind that: > Keep in mind the corporate business side of things. The Java EE 5.0 specification is still not released yet. > - 1.4 support will add complexity and require more development time > - 1.4 will become less relevant pretty quickly > - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 > Of course waiting for Java EE 5.0 and EJB 3.0 holds things up significantly if you are deploying to WebLogic Server 8.1 which is halfway to J2EE 1.4 in the first place. In other corporates cannot make the jump to Java 5 because they are waiting on Java EE 5.0 application server to be certified! Of course this may not apply to you if you are using JBoss and/or Tomcat! -- Peter Pilgrim :: J2EE Software Development & Architecture Operations/IT - Credit Suisse Group - "One Bank", Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Bob this is really a great list for doing some house cleaning. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=52211#52211 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 Bob - 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: XWork and Struts Action 2.0
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 PROTECTED]
Re: XWork and Struts Action 2.0
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 > he or she will support the release with patches and posts to the user > list. Technically, we only need three +1s to create a release, but we > like to think more than three committers will be available to support > a release. > > It doesn't matter what all the world is doing. What matters is what > the committers are doing with their own applications. We aren't > creating the framework just for other people to use. We are creating > the framework that we want to use with our own applications, and then > sharing the wealth with the general public. The Apache term is "We eat > our own dog food." Before we ask anyone else to put a release in to > production, we put it into production ourselves. So, the minimum > release platform has to match what the vast majority of committers are > now using in production. > > If the vast majority of committers are using 1.5, then 1.5 would be an > option. But that's the only argument that matters. We need the > committers to be using 1.5 at their own shops before we could consider > changing the release platform here. > > If someone were to setup that "rough spots" page, we could also > include a section where the committers could sign-up for 1.4 or 1.5 > support, based on what they are doing at work. > > -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: XWork and Struts Action 2.0
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 comes out in the fall at > which point 1.4 will be two major releases behind. We must embrace > 1.5. We should keep in mind that: > > - 1.4 support will add complexity and require more development time > - 1.4 will become less relevant pretty quickly > - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Here's the thing: 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 he or she will support the release with patches and posts to the user list. Technically, we only need three +1s to create a release, but we like to think more than three committers will be available to support a release. It doesn't matter what all the world is doing. What matters is what the committers are doing with their own applications. We aren't creating the framework just for other people to use. We are creating the framework that we want to use with our own applications, and then sharing the wealth with the general public. The Apache term is "We eat our own dog food." Before we ask anyone else to put a release in to production, we put it into production ourselves. So, the minimum release platform has to match what the vast majority of committers are now using in production. If the vast majority of committers are using 1.5, then 1.5 would be an option. But that's the only argument that matters. We need the committers to be using 1.5 at their own shops before we could consider changing the release platform here. If someone were to setup that "rough spots" page, we could also include a section where the committers could sign-up for 1.4 or 1.5 support, based on what they are doing at work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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, cohesive API doesn't preclude this separation. > I do think one problem is that our approach to referring to XWork in > the WW book and documentation is inconsistent. There is a tendency to > refer to everything as WebWork when it is not. Moving forward, I think > we simply need to be more carefult to say XWork when we mean XWork and > SAF when we mean SAF, and perhaps just refer to "the framework" when > we do not care to make the distinction. This is exactly what I'm talking about. 99.9% of users (100% of Struts users) don't care about this separation, and they have trouble with it. Even the authors have trouble keeping it straight. > No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some > future release will increment the platform, but right now, most > everyone I know is using Java 1.4 in production. Action 2.0 is meant > to be something that we can all start using in production now. 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 comes out in the fall at which point 1.4 will be two major releases behind. We must embrace 1.5. We should keep in mind that: - 1.4 support will add complexity and require more development time - 1.4 will become less relevant pretty quickly - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Ted, The below reason (3rd paragraph, man i wish yahoo did the little > things) is why we should probably decide to move XWork over now or forever hold our peace, unless of course phase I is supposed to be an alpha or preview release and phase II is mainly when Action 2 will be in production. In that case we can do anything we want and change it later. However, if we start creating a lingo and pass that lingo on to users creating production apps based on it, then changing that lingo would lead to frustrated developers. I agree that moving over XWork has it's issues (2nd paragraph), but an important question to weigh against that is how do we want to set up the framework long term. Notice how much more elegant it is to say "Struts Web", "Struts Core" and just SAF than to say SAF, XWork and "the framework" respectively. Another important question is whether we would want to go through XWork to decide what to take out and add in in preparation for action 2, for example, creating an XWork 2.0 if XWork is to stay at OS. Also, I want to make it clear that moving XWork over (1st paragraph) does not imply lumping everything together, something I am strongly against as well. In fact I was more worried about XWork related features being added to SAF 2 if they are seperate, but it seems like everyone here is pretty committed to not let that happen. Gabe - Original Message From: Ted Husted <[EMAIL PROTECTED]> To: Struts Developers List 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 definately feel that this would be too big of a change for SAF 2.0.0. No matter how simple it sounds, there would be some detail that created a showstopper, and then another, and August would turn into February. I do think one problem is that our approach to referring to XWork in the WW book and documentation is inconsistent. There is a tendency to refer to everything as WebWork when it is not. Moving forward, I think we simply need to be more carefult to say XWork when we mean XWork and SAF when we mean SAF, and perhaps just refer to "the framework" when we do not care to make the distinction. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 expose 99.9% of Struts > users to this. For starters, we should have a struts.xml, not an > xwork.xml. 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 definately feel that this would be too big of a change for SAF 2.0.0. No matter how simple it sounds, there would be some detail that created a showstopper, and then another, and August would turn into February. I do think one problem is that our approach to referring to XWork in the WW book and documentation is inconsistent. There is a tendency to refer to everything as WebWork when it is not. Moving forward, I think we simply need to be more carefult to say XWork when we mean XWork and SAF when we mean SAF, and perhaps just refer to "the framework" when we do not care to make the distinction. > I think support for generics is a must. Struts 2.0.0 will require JDK > 1.5, right? For example, getParameters() should return Map String[]>. No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some future release will increment the platform, but right now, most everyone I know is using Java 1.4 in production. Action 2.0 is meant to be something that we can all start using in production now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Ted Husted wrote: On 4/18/06, Bob Lee <[EMAIL PROTECTED]> wrote: It will be harder for me at first, but I'd like to see us take this opportunity to smooth over some of the rough spots so we don't have to break compatibility again down the road. It would be helpful if someone started a wiki page to itemize the "rough spots", which I take to mean WW2.2 legacies that we would not want to bring forward. Of course, WW has been doing this all along. WW 2.2 not only added functionality to WW 2.1, but also changed some critical defaults, like the default syntax for the tags. +1 ! Don -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: XWork and Struts Action 2.0
On 4/18/06, Bob Lee <[EMAIL PROTECTED]> wrote: > It will be harder for me at first, but I'd > like to see us take this opportunity to smooth over some of the rough > spots so we don't have to break compatibility again down the road. It would be helpful if someone started a wiki page to itemize the "rough spots", which I take to mean WW2.2 legacies that we would not want to bring forward. Of course, WW has been doing this all along. WW 2.2 not only added functionality to WW 2.1, but also changed some critical defaults, like the default syntax for the tags. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 nice that you can drop down to XWork and do non-web things, but I don't think we need to expose 99.9% of Struts users to this. For starters, we should have a struts.xml, not an xwork.xml. Both Jason and Ted mentioned compatibility. Ted, I completely support the need to maintain velocity. We've been using WebWork heavily for about a year and a half. I think maintaining backward compatibility after you release Struts 2.0.0 is an order of magnitude more important than maintaining backward compatibility with WebWork. It will be harder for me at first, but I'd like to see us take this opportunity to smooth over some of the rough spots so we don't have to break compatibility again down the road. I think support for generics is a must. Struts 2.0.0 will require JDK 1.5, right? For example, getParameters() should return Map. Thanks, Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
> 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 to vote) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51950#51950 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 about interceptors. We never access servlet classes in actions, but we sometimes need to in interceptors. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
> 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 standards, and JSTL > should be no > exception. I guess the question is whether the > overlap tags will be deleted or just deprecated. I'm > fine with deleted. > Well, the problem is, the webwork tags aren't 1-to-1 mappings with JSTL tags. It usually takes several JSTL tags to do what one WebWork tag does. I'd personally never want to use JSTL because it's too verbose and too much work. Also, what about backward compatibility for WebWork users? > > Are we going to continue using OGNL, or are we > going to use JSP EL? > > This is a good, yet complicated question that has > seen much discussion lately. The bottom line is > there are features in > OGNL that we can't live without: type conversions, > projection, and method calls to name a few. If we > can somehow either > a) extend the JSP EL to support these features or b) > implement OGNL behind the JSP EL API's, I see a > future in closer > collaboration. From what I understand, both are > possible, just waiting for someone to step up and do > the work. Did we ever hear back on the expression language JSR that was going to be submitted? If OGNL could just implement a standard API and be a drop-in replacement for JSP EL that would be great, not just for us, but for everyone using JSP who wants a better EL. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51894#51894 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
> 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 > need it, I'd prefer not to go through a ThreadLocal. Okay, so make your Action implement ServletContextAware, ServletRequestAware, etc. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51893#51893 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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. Struts has always tried to work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. One of the features I like the most about the WW tags is themes. If we move to JSTL tags, is there a corresponding feature? This is the basis for the ajax integration. I don't think this is an either/or decision, but one of eliminating the overlap. JSTL provides some formatting, conditionals, loops, and XML manipulation, while Action 2 tags provide visual and form tags. The only reason we might want to keep the Action 2 tags that overlap is if they provide value for other presentation technologies, since JSTL is only for JSP. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
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 work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. One of the features I like the most about the WW tags is themes. If we move to JSTL tags, is there a corresponding feature? This is the basis for the ajax integration. Are we going to continue using OGNL, or are we going to use JSP EL? This is a good, yet complicated question that has seen much discussion lately. The bottom line is there are features in OGNL that we can't live without: type conversions, projection, and method calls to name a few. If we can somehow either a) extend the JSP EL to support these features or b) implement OGNL behind the JSP EL API's, I see a future in closer collaboration. From what I understand, both are possible, just waiting for someone to step up and do the work. Good to see you on the list, and congrats on the marriage. I admit I was a little jealous as to its location :) Don Bob On 4/17/06, Jason Carreira <[EMAIL PROTECTED]> wrote: -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 http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716 - 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: XWork and Struts Action 2.0
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 the XWork > project and aren't > really within the scope of what the Webwork project was. Thus, if we don't > move over > XWork, an important task would be to redefine that relationship. And, IMHO, these are all issues that we should defer until after an initial SAF 2.0.0 release is made available. For now, I would suggest that we keep the focus on "phase 1" of the plan, which was to release SAF 2.0.0 based on the WW 2.2.2 codebase without making any unnecessary changes. Let's prove that we can move WebWork over and make a release, before digging into XWork. Once we have a 2.0.0 release "under our belt", then we can move forward on "phase 2", where we continue improving and evolving the codebase. If XWork would like to join the ASF, then the time to contemplate that step would be during phase 2. * http://wiki.apache.org/struts/StrutsTi We don't need to do everything in "one fell swoop". We have all the time we need, but it's important to retain project velocity so that we can release early and release often. I've just gotten back from teaching a four-day training course based on the WebWork/Action2 version of the infamous Struts MailReader. The course went well, and I'm finding that Struts Action 1 skills translate well to WebWork 2.2. It's true that to teach the whole framework, you do have to dip into the XWork jar quite often, but whether the XWork jar comes from OpenSymphony or ASF wouldn't make much difference. Like Jason, I would be -1 on (re)integrating XWork and WebWork, since that would be a slipperly slope. What we need to do most is clarify the boundary between XWork and SAF, so that web developers can see how useful separating concerns can be. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
That it is used in other places isn't necessarily a reason not to move it over. Webwork as a whole, for example, is being used in far more places than XWork alone, yet we have decided to move that over. What I would propose if we did move it over would be to keep the relationship between XWork and Webwork the way it is now but under the Struts Action Framework 2 umbrella (call it for example Struts 2 core and Struts 2 web). Thus, those projects that currently use XWork would simply depend on Struts 2 core rather than XWork. If we are able to move over the user base successfully, those XWork dependent projects would benefit as well from the increase of the user base that knows XWork, like it and want to extend its functionality. (A more solid Springwork might emerge for example). It would be easier to define documentation if they were both under a Struts umbrella as well. For example, A "webwork action" never really made sense, but a "struts action" since both would be divisions of struts would. 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 the XWork project and aren't really within the scope of what the Webwork project was. Thus, if we don't move over XWork, an important task would be to redefine that relationship. Now, the last time I wrote a message like 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. 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 http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716 - 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: XWork and Struts Action 2.0
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 standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. Are we going to continue using OGNL, or are we going to use JSP EL? This is a good, yet complicated question that has seen much discussion lately. The bottom line is there are features in OGNL that we can't live without: type conversions, projection, and method calls to name a few. If we can somehow either a) extend the JSP EL to support these features or b) implement OGNL behind the JSP EL API's, I see a future in closer collaboration. From what I understand, both are possible, just waiting for someone to step up and do the work. Good to see you on the list, and congrats on the marriage. I admit I was a little jealous as to its location :) Don Bob On 4/17/06, Jason Carreira <[EMAIL PROTECTED]> wrote: -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 http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716 - 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: XWork and Struts Action 2.0
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 two completely separate projects where one project that generates two jars would make more sense has always gotten on my nerves. I think it will be even worse now that the two projects are at different sites. 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? Are we going to continue using OGNL, or are we going to use JSP EL? Bob On 4/17/06, Jason Carreira <[EMAIL PROTECTED]> wrote: > -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 > http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716 > > > - > 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: XWork and Struts Action 2.0
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 doesn't have to go to the Commons Validator site for docs; they are well-integrated. Don Bob Lee wrote: 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 we really think it's worth it), but there's definitely no need for two separate projects. Looking in two places for the documentation and API is a huge pain, not to mention confusing for new users. Bob - 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: XWork and Struts Action 2.0
-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 http://forums.opensymphony.com/thread.jspa?threadID=26278&messageID=51716#51716 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
+1 to moving it over. I don't care about package naming, but agree the Javadocs should be in the same location. Matt On 4/17/06, Bob Lee <[EMAIL PROTECTED]> wrote: > 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 we really think it's worth it), but there's > definitely no need for two separate projects. Looking in two places > for the documentation and API is a huge pain, not to mention confusing > for new users. > > Bob > > - > 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]
