PSquad's Corner


PSquad's Corner

 ::home::  ...stuff... ::java::  ::school::  ::technology::  ::misc:: 


Tuesday, January 14, 2003

For anyone that reads my posts and thinks, "gee, that guy sure sucks at spelling", or "gee, that guy can't keep his train of thought", or "gee, that guy is an idiot", I have an answer for at least the first two thoughts (the last one I can't help you with, sorry). When I write my blog posts, I'm usually sitting in a lecture hall, crammed in with 500 other students, hopelessly trying to pay attention to the lecture while still blabbing away about some useless topic. So I hope that clears it all up.


5:22:31 PM    comment []

So I saw today that there was a blog entry discussing XWork and that it might be less powerful for the web... or less powerful as a command framework. And I'm not saying David is the one who things this, he's meerly interpreting the nonsense that is going on the WebWork mailing list. About a month ago I emailed the OpenSymphony mailing lists stating that I would no longer participate in the flamefests that so often appear on the list. Of course, I still continue to developer for a ton of the projects there and I respond to all the emails as possible (as long as they aren't pointless flames).

With that said, you may or may not know that I'm the main driver of XWork right now. I've been the one who's been mucking around in the sandbox CVS module and making lots of changes. Some have been controversial (like switching the action context from ThreadLocal to a simple Map), but the point I've made all along is that this is a play pen. A place for various developers (such as Rickard and Jason) to toy with as well. It's a very loose process that I think can work very well if the damn idiots would stop screaming and just let things play out. Once we're ready to present something, if it sitll sucks, then bitching and moaning is acceptable. Anyway, enough about the sandbox module politics, now on to what XWork is all about...

As nice as WebWork is, it has a lot of problems. In many cases, it's over engineered (just look at BeanUtil). The configuration scheme used in it can be clearly seen as one that started simple and slowly evolved but never quite grew up. What I wanted to do with XWork was start with a clean slate in terms of code, and then re-build the great ideas in WebWork, but this time go through and do it in a manner that was a much cleaner implementation. Yes, it will be a great command framework, similar to Avalon, in fact. But let me make this next part clear: it will work better for the web than WebWork does as well.

The code in CVS currently behaves just like WebWork and has all the web-based features WebWork had. But right off the bat it does one thing better: type conversion. Since the web uses Strings for inputs of all forms, inputting "YYYY/mm/DD" and having it converted to a Date object in your Action is a nice feature. WebWork did this, and it was nice. WebWork even (after my constant badgering, Matt was kind enough to get this in even during his busy sschedule) could get the Date object as a String value of "YYYY/mm/DD". But the problem here is that you couldn't customize type conversion on a per-Action or per-Attribute level. Type conversion was very static and limited. So what I did in XWork was include type conversion in the very core: The Configuration object.

But type conversion by itself is a weak argument. I know. If that was it, I would have just proposed we fix up WebWork's type conversion and possible configuration and that's it. But XWork is so much more. There are now Interceptor and Inversion of Control patterns represented (thanks Jason and JoeW!). The expression language uses Ognl, which is (arguably) much better than the old WW EL. The dispatcher code has been simplified down to the point that all you need to do is the following to have an action invocation execute:

Dispatcher d = new Dispatcher("FooAction");
// the action has already executed at this point,
// including the View, such as an action chain
// or HttpServlet request dispatcher or redirect
String result = d.getResult(); // might be "success"
FooAction foo = (FooAction) d.getAction();
OgnlValueStack vs = d.getStack();

So what this means is that in order to execute an action, all you really need to do is "new Dispatch()" and that's it. This makes using actions in a generic framework very easy. But it doesn't hurt XWork from being fantastic in the Web context. While I haven't written any taglibs yet, I have made sure that an example WAR will be part of the main deployment. So please, please, don't think that XWork is ditching the web, or that XWork won't be generic enough to justify a name change from WebWork 2.0. It's possible to achieve both goals.

And if you don't believe me, instead of sending out some flaming email to the list, I suggest you download the sources, and try to write up some use cases that won't work with the current source. Then email the list with your findings and we'll address it, because that's what we're looking for with this sandbox approach. I don't really want to hear from people that won't take at least a fraction of the time I've invested. That's not to say that I won't address their concerns, but their concerns won't take a priority at this stage. And for anyone who hasn't figured it out yet, this stage is considered exploratory.

So please... I ask anyone that cares... remember, actions speak much louder than words. And even louder than flamefests. This is sandbox, go make a mess, that's what it's there for.


3:18:17 PM    comment []

January 2003
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Dec   Feb




Copyright © 2002 Pat Lightbody