On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
ValidationAware, ErrrorAware, RequestAware, ResponseAware, SomeOtherStuffAware... Are you kidding? I might not understand something (heck, I haven't started with WW yet), but if all these interfaces are only meant to implement a callback method in a custom class for the framework to call, then... well, I do not like this.
All the interfaces are optional. So long as your "action" object has a signature that returns a string, it doesn't have to implement anything at all, not even "Action". Each of the optional interfaces define one way to solve a use case. The ValidatorAware interface defines a validate method that some people like to use. And so on. If an Action doesn't need or want to use the solution implied by the Interface, then the Action does not need to implement it. If the Action does implement the interface, then the Action can call the implemented methods directly -or- the Action can choose to let an Interceptor do the setup instead. There isn't anything you can do in an Interceptor that you could not do in an Action, if you that's the way you want to implement the acgtion.
For the lifecycle, I want a clear definition of lifecycle call sequence and an option to call lifecycle methods explicitly.
Not a problem. On it's own the framework has almost no lifecycle at all. What Interceptors fire for a particular Action is *totally* up to the developer. There's a default stack that some people preconfigure through cut-and-paste without thinking about it. But, almost nothing is hardwired. If an Interceptor files, it's because *you* configured it to fire. (Or because *you* chose to use the default configuration.) If you don't want an Action to use Interceptors, it doesn't have to. That's a decision *you* make declaratively in the configuration file.
All of them. Like in SAF1, WW binds URL to a mapping to an action, so action is the endpoint which is guaranteed to be called. Fine. Then just pass control to that action and give me an option to call all (or some) lifecycle methods explicitly from the action. I will not need interceptors in this case, by the way. And I will not need to implement a bunch of intefaces.
No you don't. The framework will happily call any method on any object you designate, so long as the method takes no parameters and returns a String. If you want to use other services of the framework from your Action, all you have do is make a call to threadlocal to obtain the Action Invocation. From there, you can do whatever you want to do, either with Interceptors or without. We could do something similar in the SAF 1 series by declaring the default Chain in the struts-config, and then letting each action-mapping use its own Chain, if it wants. What SAF 2 does with Interceptors, SAF 1.3 is starting to do with a Chain.
For the regular typecasting I agree, some interfaces are needed, to make certain methods available, but there should be a very limited number of these interfaces, and at best a particular class will need to implement only one interface. Um, does it make sense?
Well, a benefit of a framework is that we can share common solutions to common problems. Once way we share those solutions is through optional interfaces and base implementations. But, as it stands, you don't have to implement *any* interfaces at all. Not even one.
Michael.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
