Le 05-08-25 à 10:53, Craig McClanahan a écrit :
On 8/25/05, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
However, I've got a separate / semi-related question. Given that
we're changing package names anyway, it would be really cool to
abstract away the servlet API specific calling sequences, so that
standalone Tiles could work equally comfortably in a portlet
environment (without needing any portlet->servlet bridgework). The
only API a typical Tiles user will be using is Controller, so this
shouldn't be a huge deal. What do you think?
Abstracting out the servlet API will break controllers because we're
passing HttpServletRequest, HttpServletResponse, and ServletContext
to the controller's perform and execute methods. Would we change
those method signatures to take an external context instead?
If we're ever going to do this to standalone Tiles, pre-1.0 would
seem
like the right time.
I agree with that. My refactoring job pushed it up to the level of
TilesUtil. Are you saying we should take it out of TilesUtil also?
It's not just TilesUtil (your refactoring narrowed the amount of work
needed, though). A large number of the method signatures throughout
Tiles take a ServletContext, HttpServletRequest, or
HttpServletResponse parameter. None of that will work in a portlet
environment (which provides
PortletContext/PortletRequest/PortletResponse APIs) without bridging
layers to adapt backwards.
The way JSF approached this was to define an ExternalContext API that
abstracted away the differences. I'd propose to do something like
that for standalone Tiles, and pass such a context object around,
instead of the individual servlet API dependent objects.
I'm +1 for this, but should we make plugging standalone Tiles back
into Struts
a priority and tackle this once that's done? Perhaps it's unfounded,
but I'm
concerned that the current Tiles will change if we don't act quickly.
david
Craig
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
