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? > > > > 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. 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]
