Greg Reddin wrote:
On Oct 18, 2006, at 6:52 AM, David H. DeWolf wrote:
1) TilesContext is refactored into two different contexts -
TilesContext and TilesRequestContext. Only one instance of the
TilesContext should exist within the application and it will be used
to provide application scoped functions (e.g. getResource() or
getInitParameters()) . The TilesRequestContext will provide
request/response specific operations (e.g. include() or getParameters()).
At first I didn't like the separation, but now I do after looking at
your patch. It makes sense that you would put request-based stuff into
a separate class from application-scoped stuff. I have two small concerns:
1) The name TilesContext: Perhaps we should change it to
TilesApplicationContext.
Makes sense to me. I'll rename it.
2) How will Tiles be used from other frameworks? Here's an example
from Shale. Shale provides a TilesViewHandler with the following code
(the code is similar to what is used in other frameworks like Struts2's
TilesResult class):
ExternalContext externalContext = FacesContext.getCurrentInstance()
.getExternalContext();
Object request = externalContext.getRequest();
Object context = externalContext.getContext();
ComponentDefinition tile = null;
try {
TilesContext tilesContext =
TilesContextFactory.getInstance(context, request);
tile = TilesUtil.getDefinition(name, tilesContext);
} catch (NoSuchDefinitionException nsex) {
log.error("Couldn't find Tiles definition.", nsex);
} catch (DefinitionsFactoryException dex) {
log.error("Tiles error", dex);
}
return tile;
After your refactoring the code above will look like this:
ExternalContext externalContext = FacesContext.getCurrentInstance()
.getExternalContext();
Object request = externalContext.getRequest();
Object context = externalContext.getContext();
ComponentDefinition tile = null;
try {
TilesContextFactory contextFactory = new
BasicTilesContextFactory();
TilesContext tilesContext = contextFactory.getInstance(context);
TilesRequestContext tilesRequestContext =
tilesContext.createRequestContext(request, response);
tile = TilesUtil.getDefinition(name, tilesRequestContext);
} catch (NoSuchDefinitionException nsex) {
log.error("Couldn't find Tiles definition.", nsex);
} catch (DefinitionsFactoryException dex) {
log.error("Tiles error", dex);
}
return tile;
The only reason I have to create a TilesContext above is because I need
a TilesRequestContext. What if the factory provided methods to create
either the TilesApplicationContext or the TilesRequestContext instead of
the TilesContext being required to create the TilesRequestContext?
I'm fine with that. My original thought was that since the request
context has to be retrieved from various locations in the app (tags), it
may be easier to avoid propagating the availability of the factory by
providing access through the application context. The ramification of
this is that it's a little awkward in the way you described.
After looking through stuff again, I think I agree with you. I'll go
ahead and provide access to the factory through the TilesUtil. The
implementation will be modeled after the UrlDefinitionsFactory. This
consistency itself is enough of an argument for this approach.
Thanks for the great feedback. . .
David
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]
