Hello:
We would like to propose making the TilesRequestProcessor tolerant to where
it does not choke on a regular (non-Tiles) application. Actually, the
TilesRequestProcessor already "sort of" supports this, but not entirely.
Background:
In our company we have a legacy MVC framework that now wraps around Struts
1.1, and this legacy framework has its own request processor that needs to
extend either the TilesRequestProcessor or the standard Struts
RequestProcessor. Since we would like to keep things simple and do not want
to duplicate our code, we want to extend just one request processor class,
not both. That is why we decided to extend the TilesRequestProcessor and
have our request processor be used for both Tiles and non-Tiles apps.
Below are the two issues we ran into using this approach with Struts 1.1
beta 3, and how we worked around them.
Issue 1:
TilesRequestProcessor expects the TilesUtil implementation
of type TilesUtilStrutsImpl. But unless there is a TilesPlugin configured,
nobody sets this implementation.
Workaround: we extended the ActionServlet and in its init()
we are explicitly setting the implementation with
"TilesUtil.setTilesUtil(new TilesUtilStrutsImpl());"
Issue 2:
TilesRequestProcessor's initDefinitionsMapping() logs an
error, if a DefinitionsFactory has not been set, i.e. if the TilesPlugin has
not been configured.
Workaround: non needed, this is just a nuisance. The
TilesRequestProcessor still works OK.
Thoughts?
Dirk Heydtmann
Sprint PCS - CAM Architecture
(913) 794-4671
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
