Niall Pemberton wrote:
I'm probably going to say something stupid and show my ignorance of WebWork now, but number one on my list would be CoR and integrating Commons Chain commands - both as a replacement for the Struts Action and as a way of inserting custom "request processing" behaviour. I understand WW/XWork has similar Actions / Interceptors, but one of the things I like about Commons Chain is the fact that I can go develop something completely independantly of the framework with just a dependency on a small simple library. I also think that this would provide a confidence that (once Struts 1.3 is out) people could develop Commands (rather than Actions) knowing that they are in the core of a Struts 2.0. Even if there is a slight redundancy with XWork Actions / Chain Commands - I don't see this as a particularly bad thing or too much bloat.
Agreed, and in fact, my first task when I started Struts Ti was to fold in support for Commons Chain at the framework level. XWork/WebWork Actions don't even require an interface which I find superior, but I accept not everyone has the same taste as me :)
Another thing would be dynamic beans. It doesn't have to actually be a DynaBean - but some form of configuring a bean rather than coding one would be good. The other areas where our users have invested time and effort are in the configuration and the UI (taglib) and probably more importantly in their knowledge of how to develop using Struts. Someone (Martin I think) proposed providing migration tools for things like configuration, rather than supporting (in the core) things like the struts-config.xml. I think this is one approach and a good idea rather than bloating the core with stuff thats there for backwards compatibility only. However if there are things we can do in the *core* that reduces the learning curve of adopting a new framework for Struts users then I don't think they should be ruled out by Struts 2 == WebWork 2.2.
Sure, and these things will become apparent as we start working with the code. What I said Struts 2 == WebWork 2.2, I was more referring to the initial import and perhaps release. I agree there are things in Struts that we will want to migrate.
At this point in time the attitude seems to be "don't worry WebWork is not changing, except for package names" and that gives me some concern and I'm hoping that WebWork is coming to the party more in the spirit of a merger and be prepared that there may be changes and that Struts 2.0 is may not be exactly WebWork 2.2? Don't get me wrong, I'm broadly in favour of this merger - although thats based solely on WebWorks reputation and not knowledge of their software and maybe once I'm better informed I'll be more in the "yeah lets throw struts away, WebWork is great as it is camp". Another thing I'd like to know is could someone clarify what would come to Struts. Does XWork come with it or is that staying at open symphony. I tried to find a list of dependencies on the WebWork side, but couldn't - what are WebWorks dependencies? Also if XWork is staying at Open Symphony I'd like to know more about that organisation. Their web site is a .com, the license says its based on Apache - but it doesn't really say anything about what type of organisation Open Symphony is?
XWork is staying at Open Symphony. OpenSymphony has been around for a while, and I haven't heard anything bad about them, other than they used to have difficulty keeping their wiki up a while back. I think Atlassian runs their infrastructure now for them.
Don
Niall --------------------------------------------------------------------- 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]
