On Mon, 28 Oct 2002, David Graham wrote:

> Date: Mon, 28 Oct 2002 12:28:48 -0700
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Modules vs. Sub-Applications
>
> I was suggesting deprecating the names in a future version and moving to all
> "module" names for clarity, not necessarily removing the functionality.

Hmm ... I'm still of two minds on this one ...

> What benefits would making the ActionServlet into a Filter provide? It is an
> interesting idea.

Just as one example, you know how some people persist in linking directly
to a JSP page and thereby bypassing the functionality built in to the
controller (such as automatic selection of the correct sub-application,
err, module :-).  This wouldn't be a problem if the controller were a
Filter.  You could also envision things like decomposing the controller's
functions into individual filters, and letting a particular app compose a
filter chain that only implemented the parts they cared about.

One potential problem (at least under Servlet 2.3) is that filters don't
get invoked on a RequestDispatcher include or forward call, so we'd have
to make sure that it still operated as expected in those scenarios.  This
was addressed in Servlet 2.4, by letting you optionally ask for that
service.

>
> David

Craig

>
>
>
>
>
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: Struts Developers List <[EMAIL PROTECTED]>
> >Subject: Re: Modules vs. Sub-Applications
> >Date: Mon, 28 Oct 2002 11:11:17 -0800 (PST)
> >
> >
> >
> >On Mon, 28 Oct 2002, David Graham wrote:
> >
> > > Date: Mon, 28 Oct 2002 11:24:36 -0700
> > > From: David Graham <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Modules vs. Sub-Applications
> > >
> > > Would it make sense to keep the current names but deprecate and replace
> >them
> > > in a future version (maybe 2.0)?
> >
> >To me, deprecating them in 1.1 would imply that we'd really like to remove
> >them in 1.2 or 1.3 (if there ever was such a thing).  And I don't think
> >that's necessarily what we want to do (although it might).
> >
> >If we implemented all of the wild ideas I know of already for 2.0 (such as
> >making the controller a Filter instead of a Servlet), there would likely
> >be very little similarity between 1.x and 2.x other than the product name.
> >We're going to have to very carefully hash out what we think the roadmap
> >should be, before we really have much of an idea on what 2.0 will hold and
> >therefore what deprecstions it might imply.
> >
> > >
> > > David
> > >
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> >For additional commands, e-mail:
> ><mailto:struts-dev-help@;jakarta.apache.org>
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
> --
> To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to