On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote: > Niall Pemberton wrote: > > Its probably a great plan to switch to WebWork 2.2 but I still don't > > see how you can say its a "merger" if no Struts code is involved - > > merger in terms of community, but not software. > > I view this merger as first, one of projects/community, and second, one of > code.
For WebWork I agree, but from a Struts perspective its the other way round, although if WebWork code is as good as its reputation then the WebWork developers (Patrick, Jason, anyone else?) will be very welcome additions to our community. > Just because the Struts Action 1.x compatibility layer will be separate from > the Struts Ti core (WebWork 2.2), doesn't mean we haven't merged code. In > fact, > I'd consider that a prime example of the merger, because the Struts Action > code > will need to be "merged" into the Struts Ti core framework while retaining > much > of its original functionality. OK, but when I hear "optional compatibility" to me it sounds like a "deprecated" warning (i.e. you can use it for now but you really need to move on before this disappears) and I had thought that there would be some things that merged from Struts into the *core* of a Struts 2.0. 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. 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. 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? Niall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
