struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Molitor" <emoli...@molitor.org>
Subject Re: Public API first draft
Date Thu, 04 May 2006 20:39:47 GMT
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 <jmikus@gmail.com> wrote:
> On 5/4/06, Eric Molitor <emolitor@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


Mime
View raw message