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
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 - 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
--- 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
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=26278messageID=52269#52269 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rough Spots (was: XWork and Struts Action 2.0)
Also, should we seperate these issues as XWork and SAF issues? The XWork issues can just be entered into XWork JIRA and linked to from this page. (Some are already there). Then, this page can serve as a list of the critical issues before release. - Original Message From: Jason 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 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=26278messageID=52269#52269 - 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
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=26278messageID=52293#52293 - 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
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
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
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
+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
+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 for struts-action.xml - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=52352#52352 - 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=26278messageID=52373#52373 - 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
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
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=26278messageID=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
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
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=26278messageID=51893#51893 - 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
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=26278messageID=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: 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 MapString, String[]. 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, 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 MapString, 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, 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 dev@struts.apache.org 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, 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]
[action2] Java 5 support (was XWork and Struts Action 2.0)
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 too far behind. Does anyone have any experience with such an approach? Don [1] http://retroweaver.sourceforge.net/ Bob Lee 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 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: 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
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: 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
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]
XWork and Struts Action 2.0
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]
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=26278messageID=51716#51716 - 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
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=26278messageID=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=26278messageID=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
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=26278messageID=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]
