Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don't worry, David. We're just talking about cleaning up the API and making your code a little cleaner. It's fundamentally the same framework with the same philosophies. Bob On 5/5/06, David Evans [EMAIL PROTECTED] wrote: I am a struts user who has recently began programming in webwork, to get a head start for action 2. Having just spent many hours researching, reading about and experimenting with webwork, I personally hope that you start with a version of action 2 that resembles webwork pretty closely. I wonder how many other people are in my shoes. If ease of migration is a major concern for the project, maybe a survey on struts-user would be useful, something like: Regarding Struts Action 2 and Webwork do you... [ ] plan to keep using struts action 1 for new apps [ ] plan to use struts 2 for new apps when released [ ] plan to use webwork for new apps til struts 2 is released I think that having the current webwork user base as a resource that may help the much larger struts users base to migrate is a consideration that should be taken in your deliberations as well, because if struts action 2 is new everyone, that may make adoption slower. Dave On Fri, 2006-05-05 at 13:04 -0700, Don Brown wrote: Ok, let's just make this an official proposal and focus all of this discussion: I propose that the architecture plan for Struts Action 2.0 includes the following: 1. A re-design of the API to simplify the framework the users see 2. Backwards-compatibility support for WebWork 2 and Struts 1.x applications 3. Continue to use XWork for a) compatibility reasons and b) the core implementation of the new API 4. A target GA release by August This means for current WebWork 2 users: 1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x branches 2. Migration to Struts Action 2.0 should take hours, not days, weeks, but probably not minutes. For Struts Action 1 users: 1. Struts Action 1.x will continue to be developed actively 2. Migration to Struts Action 2.0 should take days, using available migration tools and compatibility libraries I think this proposal is a good middle ground between folks that want WebWork 2.2 with just package renaming, and others that want a completely new framework. Please register your comments and if necessary, I'll call a vote so we can decide this once and for all, and get back to coding. 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]
[action2] maven dependency version
Hi guys, A newbie suggestion on current SAF2.0 maven build, I am thinking of putting all dependency version under dependency-management./dependency-management instead of have them specified under dependency.../dependency of project level pom and subproject pom overwrite them accordingly. It makes it easier to manage dependency, just in case we need to change them latter on. Currently I think the dependency-management .../dependency-management could go into project level pom. But user could extract them and let them in settings.xml under ~/.m2/ or maven-install-dir/conf makes it easier for them to change the dependency if the wish more easily as well. Is this the correct way to deal with it? I mean does other projects in Apache do it this way? Is the the recommended practise? cheers.
[Struts Wiki] Update of StrutsMaintenanceMaven by WendySmoak
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by WendySmoak:
http://wiki.apache.org/struts/StrutsMaintenanceMaven
The comment on the change is:
add settings.xml schema
--
~/.m2/settings.xml
{{{
- settings
+ settings xmlns=http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
...
servers
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's the goal of SAF 2.0? (was Public API first draft )
If you looked at the Struts Ti proposal, you'd see that the goal was to start developing advanced features to dramatically simplify development. The whole reason we looked at WebWork in the first place is we wanted a solid foundation so that we could focus on features. With the merger comes an opportunity for the WebWork developers primarily to clean up the API and rethink a few things. However, the API discussions we've had so far make it clear these are API cleanups, not fancy new features. I must disagree. Bob and Patrick's first cut at the API is a NEW API, not a cleanup. It's very different from an end-user perspective, even if we could implement it with what we've got. Therefore, to state once again, our goal in this first phase is to keep the feature changes, the end user stuff, minimal so that we can get a solid release out quickly. The second phase focuses on fancy new features like annotations, zero config, quick deployment, or whatever else we want to try. Well, that's why I asked, because these are not minimal changes to the end user API. This is why Ted pointed out the current Struts Action 2 proposal is really just a clarification of the original Struts Ti proposal. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29563messageID=57555#57555 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FrontPage by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/FrontPage -- * [:Shale:StrutsShale] -- A proposal for a next generation Struts architecture * StrutsTi -- A proposal and discussion pages for a next generation Struts architecture focusing on simplicity * [StrutsMoreAboutJSF] -- JSF vs. Struts (Is this still relevant?) + * StrutsAction1Planning -- Ideas for new versions of Struts Action Framework 1. * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion * [SAF1RoughSpots] -- Discussions of what can be done to continue the evolution of Struts Action1 Framework - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
Don't worry, David. We're just talking about cleaning up the API and making your code a little cleaner. It's fundamentally the same framework with the same philosophies. Bob Maybe the same philosophies, but the API you laid out is very different for users of the framework... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29563messageID=57556#57556 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsAction1Planning New page: = Struts Action Framework 1 Planning = This page collects ideas and discussion on what could be included in future releases of Struts Action 1. This page is a whiteboard, meaning no one has committed to anything and therefore its purpose is to share information and brainstorm. == 1.3.x and beyond == The 1.3.x series utilizes Struts Chain as the default request processor and adds an extends attribute to all the configuration elements (a la Tiles). We would also like to add a Ant-style properties file to make variable substitutions within the XML elements. The substitution feature is supported by Spring and iBATIS, among others. Substitutions are a useful way to configure applications and reduce redundancy. == Experimental Members == To lay the groundwork for future changes, three experimental classes and interfaces are being added to the framework so that early adopters can experiment with using Struts Chain to develop applications. We do consider these members experimental, and they are subject to change, based on our experience using them with our own applications. '''ActionCommand''' - A Chain Command-like interface with one method: void execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. '''ActionContext''' - A Chain Context that implements the logical Action class API. Existing code could be converted by changing references to context.* and so forth. The context could be constructed by the Request Processor, as an optional Command in the Chain, so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface. '''ViewContext (pending)''' - A Chain Context that implements the logical Velocity Tools API. In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked experimental. The Commons Chain WebContext we now pass around Struts Chain could be called the StrutsContext to differentiate it from the ActionContext and ViewContext. (Are we now starting to call everything Context instead of Action? Not really. We use the Context suffix when a member extends Chain Context. This convention is unlike the current Action soup, since Context is a suffix that identifies a member's family history.) Another experimental member is the catalog element, which could be used to to support using a Chain of ActionCommands in lieu of an Action. == Struts Action Framework 1.4.x considerations == One we get past 1.3.x, there are some other things that we might consider. Consider combining DTDs. Right now, using standard extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground. == Struts Action Framework 1.5.x considerations == Based on our own work with the experimental members introduced in 1.3.x, we might consider some other changes. '''Consider a smart action type'''. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even try placing an ActionCommand interface on ActionForm, so people could skip having a seperate Action or ActionCommand class. The ActionForm could do it all. '''Consider a populate method on ActionForm'''. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on a god class to populate it from
[Struts Wiki] Update of StrutsAction1Planning by DonBrown
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsAction1Planning
--
To lay the groundwork for future changes, three experimental classes and
interfaces are being added to the framework so that early adopters can
experiment with using Struts Chain to develop applications. We do consider
these members experimental, and they are subject to change, based on our
experience using them with our own applications.
- '''ActionCommand''' - A Chain Command-like interface with one method:
+ '''!ActionCommand''' - A Chain Command-like interface with one method:
-
+ {{{
void execute(ActionContext context)
+ }}}
Support for conventional Actions would stay in place, but as an alternative,
a class could implement ActionCommand and unbind itself from the HTTP API.
- '''ActionContext''' - A Chain Context that implements the logical Action
class API.
+ '''!ActionContext''' - A Chain Context that implements the logical Action
class API.
Existing code could be converted by changing references to context.* and so
forth. The context could be constructed by the Request Processor, as an
optional Command in the Chain, so that it could be exposed this through
thread-local, opening the door for POJO actions that don't implement a
particular interface.
- '''ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
+ '''!ViewContext (pending)''' - A Chain Context that implements the logical
Velocity Tools API.
- In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the ViewContext. View technologies
could then look exclusively to the ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
+ In a later release, when the new members stabilize, we could move the taglib
dependencies from the servlet contexts to the !ViewContext. View technologies
could then look exclusively to the !ViewContext rather than poke around in the
various servlet contexts. (Of course, support for the original architecture
would remain for some time, to give third party libraries the chance to
migrate.)
- After having a chance to work with ActionContext and ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
+ After having a chance to work with !ActionContext and !ViewContext ourselves,
we could introduce more support for these members in a later release. But for
1.3.x, they could be marked experimental.
- The Commons Chain WebContext we now pass around Struts Chain could be called
the StrutsContext to differentiate it from the ActionContext and ViewContext.
+ The Commons Chain !WebContext we now pass around Struts Chain could be called
the !StrutsContext to differentiate it from the !ActionContext and
!ViewContext.
(Are we now starting to call everything Context instead of Action? Not
really. We use the Context suffix when a member extends Chain Context. This
convention is unlike the current Action soup, since Context is a suffix
that identifies a member's family history.)
- Another experimental member is the catalog element, which could be used to to
support using a Chain of ActionCommands in lieu of an Action.
+ Another experimental member is the catalog element, which could be used to to
support using a Chain of !ActionCommands in lieu of an Action.
- == Struts Action Framework 1.4.x considerations ==
+ == Struts Action Framework 1.4.x considerations ==
One we get past 1.3.x, there are some other things that we might consider.
- Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
DynaForm configuration.
+ Consider combining DTDs. Right now, using standard extensions like Tiles
and Validator mean using more than one configuration file. While using multiple
configurations files can be a good thing, we should also try and support the
idea of having a single configuration file. This might not work-out for Tiles,
but we might be able to at least integrate the Validator configuration with the
!DynaForm configuration.
- Consider refactoring for Spring. We identified the need for adding a IOC
container to Struts some time ago, but stalled on the point of which to use.
Since then, Spring
Re: What's the goal of SAF 2.0? (was Public API first draft )
Jason Carreira wrote: If you looked at the Struts Ti proposal, you'd see that the goal was to start developing advanced features to dramatically simplify development. The whole reason we looked at WebWork in the first place is we wanted a solid foundation so that we could focus on features. With the merger comes an opportunity for the WebWork developers primarily to clean up the API and rethink a few things. However, the API discussions we've had so far make it clear these are API cleanups, not fancy new features. I must disagree. Bob and Patrick's first cut at the API is a NEW API, not a cleanup. It's very different from an end-user perspective, even if we could implement it with what we've got. Please don't judge until we are done. We need to first agree on our design goals, then we can pick through implementations. The proposal is about agreeing to the laid out design goals, but it is too early to say that we are or aren't meeting them. First cuts are never put into production as is, and this API is no different. Besides, even if we did finally go with something more sweeping, to make it acceptable under the original agreed upon proposal, we'd have to ensure existing apps would be able to migrate in hours so you can be sure the end user will have a smooth migration. Otherwise, we'd have to move the API to a new version. What we need here is cooperation and a willingness to compromise and follow a common path that may not be exactly what everyone wants, but it is what the community agreed is best for the project and its users. My guess is you will always think a new API goes too far, Bob will think it doesn't go far enough, and the rest of the developers will lie along that spectrum. We could either fight every step of the way to force our point of view, or we could work together to find a common vision. I think we owe it to our users to do the latter. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action][Proposal] Architecture plan for Struts Action 2.0
On 5/6/06, Jason Carreira [EMAIL PROTECTED] wrote: Maybe the same philosophies, but the API you laid out is very different for users of the framework... Let's not exaggerate the impact of the API on user code though... Users record validation errors a little differently; you should be able to port existing WW2 code pretty easily with some clever refactorings (which we will document when the time comes). And we're trying to simplify custom interceptor and result implementations. How many custom interceptors and results does a typical user implement? Not many. The new API should be simpler, cleaner, better separated from the implementation, more intuitive, and better organized. If you understand WW2, you'll have no problem understanding the new API. If you haven't learned WW2 yet, it will be easier to learn the new API than WW2. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StrutsAction1Planning wiki page
Don, have you considered combining these two pages: http://wiki.apache.org/struts/StrutsAction1Planning http://wiki.apache.org/struts/SAF1RoughSpots or your plan is to have SAF1RoughSpots as discussion board, and StrutsAction1Planning to reflect decisions agreed upon (I mean, agreed upon that they make sense, but not necessarily that Struts team is committed to implement them). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsAction1Planning wiki page
I'm fine with combining them. I'm currently going through the website and updating it, and felt this particular information would be better suited for the wiki. Feel free to reorganize it in a more useful format or combine it with similar pages. Don Michael Jouravlev wrote: Don, have you considered combining these two pages: http://wiki.apache.org/struts/StrutsAction1Planning http://wiki.apache.org/struts/SAF1RoughSpots or your plan is to have SAF1RoughSpots as discussion board, and StrutsAction1Planning to reflect decisions agreed upon (I mean, agreed upon that they make sense, but not necessarily that Struts team is committed to implement them). - 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]
