We have a lot of flowscripts that typically assemble request parameters and information from the session and then create new Java objects which are sent to "createX" or "saveX" methods on DAO objects. These functions are usually around 20 lines of code, sometimes longer. In theory we could delegate these to Java objects, but if we pass in the request object then the Java objects would need to know about Javascript to unwrap the request. Here's an example of one of our flowscript functions:<snip/>
Do you think this is too much logic for a flowscript function? If so, how would you deal with it?
No, I don't think there's much logic there at all. It's a bit verbose though. You might try defining a Javascript-aware helper Java class, pass the request and/or session to its constructor, have it unwrap them, extract the needed parameters and store them in fields. Then pass the instance of the helper to your business methods.
If you don't want your business objects to depend on the helper's implementation, you can have the latter implement an interface that declares only the getters. Thus, you get also the benefit that you can now unit test your business methods by passing them a mock implementation of the interface.
This amounts to a "Parameter Object" kind of pattern (see Martin Fowler, "Refactoring", pp. 295). I wouldn't recommend it if you only have a handful of parameters, but if you have more, it can be useful. It also might help when some parameters are required to have default values, unless some specific value is indicated in the request. You can just initialize the parameter object with default values at construction time.
To sum it up: the Parameter Object would have to depend on Javascript, but you can hide this dependency behind an interface.
Hope this helps,
Ugo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
