I have a logic layer in my app, between the model objects and the webwork actions (or any other calling code). It provides a service-type interface for working with the model objects. Behind that interface, all of the interesting things that have to happen to fully perform each action take place, including transaction management, authorization, event publishing, etc. These are actions that are part of the business logic of the system.
The reason I'm using xwork is two-fold: 1) It lets me do things AOP-style at the logic level, so transaction management, authorization, event publishing, or any corollary actions can be handled by drop-in interceptors. I've already written an authorization interceptor that seems to work pretty well (using my home-grown auth engine) and will work on the event one later (making asynch publish calls, most likely to JMS). This works for other things, too, like for a "FileAttachment" model object, I can use an interceptor to control the actual file writing and reading, and let the model objects just store their data via hibernate. 2) I use MDA pretty heavily. I'm a small shop and have a lot of projects going on. If I can code-generate a bunch of boiler-plate code, I can get more done and make more money. Using the command framework lets me continuously regenerate my model objects as they change, while keeping things that can't be code generated out in the interceptors. The "FileAttachment" object I mentioned before is a perfect example. If the users decide they want to add "comments" to the "FileAttachment" object, I can regenerate the whole thing, including hibernate config, table scripts, model objects, webwork actions, etc. If I had the custom code for actually saving and reading files in the model class itself, that would be overwritten every time I regenerated. Instead, I drop it in via a logic interceptor, which is configured in a file that doesn't get overwritten (I make use of the multiple config files in xwork, too). I could put this stuff into subclasses of my generated classes, but I've found that it's cleaner to let the model objects take care of business logic at a lower level, like calculating things, rather than dealing with things that might require access to external systems (like a file system) or that have to make explicit calls to Hibernate or other system components. I prefer to keep my model objects as system agnostic as possible. So I guess I use it for AOP but at the logic level, not the system level. So far it seems to be a good idea, but who knows, maybe 6 months from now I'll be hating myself. I do know that xwork adds very little overhead, if any at all, and works like a charm. I'm going to be pulling out the base class methods for my actions that get a hibernate session and put it into an xwork component, so I'm probably getting in deeper with xwork. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Carreira Sent: Wednesday, August 20, 2003 12:30 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Simplicity of WW2 Hey, just out of interest,what are you using Xwork for standalone? > -----Original Message----- > From: Drew McAuliffe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 1:41 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Simplicity of WW2 > > > Agreed. I like things being simple but I don't like making > things confusing and awkward in the name of simplicity. > > If some sort of "default" action thing does get put in, > though, I would recommend that it be specific to webwork. > Xwork doesn't need it; it's really only appropriate for > simplifying web development (though it will only simplify > things for the first 10 minutes you use webwork and then get > in your way after that). If you're using xwork standalone > (which I am), it has the potential to create subtle, > difficult to track errors. A command framework should only > implement the commands that are explicitly stated. If a web > framework wants some default commands to make web development > easy, then more power to it. > ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
