I'd also like to point out that it's possible to view XWork as a different product than WebWork. I don't know if that's the intent, but XWork seems to be slightly hamstrung by trying to be "WebWork 1.4 nee 2.0" - which may be acceptable, maybe not.
It may be in its best interest to say "Well, we're trying to minimize the impact, but let's be real, we're tossing enough out to say that it's webwork-inspired, not webwork 2.0." That gives you a lot of freedom to retain what makes sense from a project standpoint, while accepting that some users will want to retain webwork's foibles and quirks instead. (I may be one of those, depending on the high-quality docs that are sure to follow an XWork release.) On Mon, 30 Dec 2002, [ISO-8859-1] Rickard Öberg wrote: > Vedovato Paolo wrote: > > I think that it's a very important point to be able to switch to XWork > > without having code changes AND to have all the improvements (like > > performance etc.). > > Hm... not sure if that's realistic. Switching with minimal code changes, > yes, but with no code changes I don't know. For example, *Aware > interfaces should be gone. We might want to reconsider how context and > pre/post processing is done too. For example, it would be entirely > possible to use Action implementation wrappers instead of ActionFactory > delegates (i.e. do stuff on execute() instead of on getAction()). Since > I think most of us are seeing needs for that already (e.g. validation, > security, various pre-processing) that would be a nice way to handle it. > And it could also be an alternative way to do chaining. > > > So if there is extra work to achieve this it should really be considered. > > That would lead to a really fast usage of XWork through the WebWork > > community. > > Really Fast Usage of XWork is not the primary concern IMHO. I would MUCH > rather have XWork be AS GOOD as it can be from both design and > performance point of views, and have usage delayed somewhat. Having a > compromised solution that only goes half the way is only going to hurt > in the end. > > /Rickard > > --------------------------------------------------------- Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.com IT Consultant ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
