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.
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?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
