On this I agree mate ;) Xwork will still be primarily a web framework, I think everyone is saying that. But as far as possible we should allow non web uses if we can.
(Like the abstraction of session out - it's neater that way AND enables non web uses) Cheers, Mike PS For the record I've never written a Swing app (other than a few tests) and don't intend to anytime soon ;) On 13/1/03 6:30 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words: > Mike Cannon-Brookes wrote: >> Some points that people seem to be forgetting: >> - Xwork is in the SANDBOX and is eXperimental (if you like the X for that) >> - Nothing in Xwork can't be changed, these are ideas, prototypes >> - Xwork will be better for 'web work' than WebWork is! >> - Xwork will be better for 'non web work' than WebWork is, _WITHOUT_ >> impacting people who don't care for 'non web work' > > But the experimental sandbox is not emerging out of thin air. It is > based on ideas, which are molded through various requirements. If there > are two different sets of requirements, they lead to different ideas > which lead to different code. If we can't agree on the requirements > (a.k.a. goals), then that is much more important to discover than > "writing cool code" and THEN discovering that we're not after the same > thing. > > That WebWork turned out to be a generic command pattern was more of an > accident then by design. Because of this genericity WebWork is not > optimally designed for doing web work. Some of the "plumbing" needs to > be done by actions themselves, instead of having it be done by the > framework. I want to make WebWork/XWork *better* suited for the web, > because that is what *I* *need*. I want to get more for less. I don't > give a damn about making it work well in Swing. If it does, then > whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point > where I need to decide between "keeping genericity, or making it work > better for the web", the latter is a given. My recent emails have > explained some of what I want to do in this area (introducing packages > and components for example). Some of those are VERY web-centric, and > that *IS THE POINT*. > > MAYBE it will never come to the point where there's such a decision, but > there is a clear difference in what happens at that point in these two > projects. In WebWork it is clear that if a decision benefits the web, > then the web option it is. In XWork it is equally clear that if a > decision may benefit the web but not Swing/EmailDispatcher/XDispatcher, > then the generic option it is. This is how we have talked about the > differences between WebWork and XWork, and this is the consequence of > such different goals. I personally prefer the WebWork option, always. If > you don't agree with my conclusions, then we have a different view of > what the purpose of XWork is. I'm just going by what we have said are > the intentions of this project. > > /Rickard > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
