You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Eric Molitor <em...@molitor.org> on 2006/05/04 20:43:50 UTC
Re: Public API first draft
I definitely agree that they should be isolated, but glancing through
the api I saw RequestAware but not ResponseAware. (I`m reading the
copy Don posted and not the version under source control.)
On 5/4/06, Bob Lee <cr...@crazybob.org> wrote:
> On 5/4/06, Eric Molitor <em...@molitor.org> wrote:
> > In regards to the implementation of the API where did ResponseAware
> > go?
>
> org.apache.struts.action2.servlet.ServletResponseAware
>
> I put these interfaces in a sub package because users should avoid
> creating dependencies on the servlet API in their actions.
>
> Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Public API first draft
Posted by Eric Molitor <em...@molitor.org>.
Actually my point was the Servlet*Aware interfaces should be isolated
as their use is generally a bad practice. There was some confusion as
to what RequestAware was doing.
If you have to implement 35 interfaces to implement an action then
obviously this would not be a viable framework. In most cases you
would be using few, if any, of the interfaces.
Cheers,
Eric
On 5/4/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 5/4/06, Eric Molitor <em...@molitor.org> wrote:
> > I definitely agree that they should be isolated, but glancing through
> > the api I saw RequestAware but not ResponseAware. (I`m reading the
> > copy Don posted and not the version under source control.)
>
> 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.
>
> For the lifecycle, I want a clear definition of lifecycle call
> sequence and an option to call lifecycle methods explicitly. 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.
>
> 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?
>
> Michael.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Public API first draft
Posted by Don Brown <mr...@apache.org>.
Leon Rosenberg wrote:
> On 5/5/06, Ted Husted <te...@gmail.com> wrote:
>> On 5/4/06, Michael Jouravlev <jm...@gmail.com> 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".
>
> And how does the controller (or whatever) "find" this method?
> reflection? Is this thought to become cached? I mean reflection isn't
> the fastest, is it?
The beautify of having the Action implement an interface is you don't
have to use reflection. The interceptor gets the Action object, then
does a simple instanceof check to see how to handle it.
Don
>
> Besides, I find the *Aware interfaces pretty cool.
>
> regards
> Leon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Public API first draft
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 5/5/06, Ted Husted <te...@gmail.com> wrote:
> On 5/4/06, Michael Jouravlev <jm...@gmail.com> 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".
And how does the controller (or whatever) "find" this method?
reflection? Is this thought to become cached? I mean reflection isn't
the fastest, is it?
Besides, I find the *Aware interfaces pretty cool.
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Public API first draft
Posted by Ted Husted <te...@gmail.com>.
On 5/4/06, Michael Jouravlev <jm...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Public API first draft
Posted by Michael Jouravlev <jm...@gmail.com>.
On 5/4/06, Eric Molitor <em...@molitor.org> wrote:
> I definitely agree that they should be isolated, but glancing through
> the api I saw RequestAware but not ResponseAware. (I`m reading the
> copy Don posted and not the version under source control.)
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.
For the lifecycle, I want a clear definition of lifecycle call
sequence and an option to call lifecycle methods explicitly. 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.
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?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org