Uhm, I tried to use only methods with request/response pairs and I have strange artifacts in response. Just for an example, the "testinsertdefinition.jsp" have the following response:
/*SNIP*/ <table border="2" width="300" bordercolor="Gray"> <tr> <td bgcolor="Blue"><strong>This is the title. <strong>This is the header</strong> <div align="center"><b><i>This is a body</i></b></div></strong></td> </tr> <tr> <td></td> </tr> <tr> <td></td> </tr> </table> /*SNAP*/ As you can see, the tiles are rendered in the wrong place. What I did not consider is that a PageContext is not merely a collection of a request, a response and a page scope. The solution could be letting the TilesContainer expose only methods with TilesRequestContext, moving the "getContextFactory" to the TilesContainer interface and working only with TilesRequestContexts. Yes, I know that this means more code to write, but at least everything is consistent. Thoughts? Antonio 2007/2/21, David H. DeWolf <[EMAIL PROTECTED]>:
Antonio Petrelli wrote: > Hi! > I have filed a JIRA issue about the removal of JSP dependencies and, > following David's suggestion, I am starting a thread about find a good > approach to solve this issue. > http://issues.apache.org/struts/browse/TILES-114 > > Thinking out a bit I think that we may: > > * create "TilesPageContext" class, extending from > "TilesRequestContext", plus a "getPageScope" method. What's the purpose of this new interface, it seems page specific? Or, do you mean that this is a JSP specific implementation of the TilesRequestContext? How would the getPageScope be used internally? > > * create a "TilesPageContextFactory" that creates a TilesPageContext > from an object (in the case of JSP it is a PageContext). > The two factories should be separated because TilesContextFactory > creates contexts from the "controller" technology (servlet, portlet, > etc.), while TilesPageContextFactory creates it from "view" technology > (JSP, FreeMarker...). Ok, I think this answers my previous question :). You really do mean a new interface, so I'm not sure how it'd be used. Are you suggesting that there would be two types of container methods: For controllers: render(request, response, definitionName) and for view technologies: render(object, definitionName) If so, why do we need the seperation? Why not just make the TilesContextFactory implementation for jsp smart enough to convert the pageContext into a TilesRequestContext? We could pass the PageContext as both the request and the response. I'm not sure I understand the need for view technology specific features here? Is it just a convenience? > This is OK for JSP, but maybe for Velocity and FreeMarker it is a > problem, since I suppose that a "Velocity PageContext" is made of a > context for velocity plus request plus response (the same for > FreeMarker). I suppose that varargs is not a viable choice. Keeping things to the standard: render(request, response, definition) and forcing the factories to handle them consistently, allows us to centralize the burden of creating the context on the factory. > > * Replace the type "Object" instead of PageContext in API. Or just remove that series of methods, right? > > Thoughts? > > Ciao > Antonio >
