You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Heydtmann, Dirk [PCS]" <dh...@sprintspectrum.com> on 2003/01/09 00:31:15 UTC
TilesRequestProcessor in non-Tiles applications
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: TilesRequestProcessor in non-Tiles applications
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Can you post this as an enhancement request in bugzilla ?
Goal: be able to use the TilesRequestProcessor even if it not
initialized from the TilesPlugin.
Cedric
Heydtmann, Dirk [PCS] wrote:
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: TilesRequestProcessor in non-Tiles applications
Posted by Hal Deadman <ha...@Tallan.com>.
Could you configure the Tiles plug-in first and then have your own plug-in
swap in your RequestProcessor implementation that extends
TileRequestProcessor? Then you might not need to extend ActionServlet. Not
sure if you can be sure what order the plug-ins run. Just a thought, haven't
looked into it.
> -----Original Message-----
> From: Heydtmann, Dirk [PCS] [mailto:dheydt01@sprintspectrum.com]
> Sent: Wednesday, January 08, 2003 6:31 PM
> To: Struts Developers List
> Subject: TilesRequestProcessor in non-Tiles applications
>
>
> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>