[Standalone Tiles] TilesRequestProcessor and TilesPlugin

[br...@tariffenet.it]

I noticed that TilesRequestProcessor and TilesPlugin have disappeared from
Tiles standalone.
I know that TilesPlugin absence could be replaced with TilesServlet (I
think it only initializes the definitions factory, correct me if I am
wrong) but TilesRequestProcessor is useful for Struts users.
I was used to forward directly to a definition:
mapping.findForward("name.of.the.tiles.definition");
Without TilesRequestProcessor I can't do that... or there is a way to do
so that I still don't know?
I know that Struts users can use "Struts Tiles" but I think that the
independence of Tiles Standalone must not remove its history of being a
part of Struts.
What do you think of "reintegrating" at least TilesRequestProcessor?
Cheers
Antonio Petrelli


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

[Joe Germuska <Jo...@Germuska.com>]

At 12:54 PM +0100 12/1/05, <br...@tariffenet.it> wrote:
>I noticed that TilesRequestProcessor and TilesPlugin have disappeared from
>Tiles standalone.
>I know that TilesPlugin absence could be replaced with TilesServlet (I
>think it only initializes the definitions factory, correct me if I am
>wrong) but TilesRequestProcessor is useful for Struts users.
>I was used to forward directly to a definition:
>mapping.findForward("name.of.the.tiles.definition");
>Without TilesRequestProcessor I can't do that... or there is a way to do
>so that I still don't know?
>I know that Struts users can use "Struts Tiles" but I think that the
>independence of Tiles Standalone must not remove its history of being a
>part of Struts.
>What do you think of "reintegrating" at least TilesRequestProcessor?

You can't have a "standalone Tiles" with a dependency on the Struts 
RequestProcessor!

I would think that if you were using the TilesServlet mapped to 
handle requests for "*.tiles" then

><forward name="success" path="name.of.the.tiles.definition" />

would just become

><forward name="success" path="/name/of/the/tiles/definition.tiles" />

or something similar depending on how the TilesServlet maps paths to 
definitions.

I haven't tried this, but it seems to make sense.

If we did end up needing/wanting to provide some support for Tiles in 
Struts beyond the standalone, we'd probably create a "struts-tiles" 
subproject which depended on Struts and Tiles and added any plugins, 
request processors or other code which bridged the two projects.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [Standalone Tiles] TilesRequestProcessor and TilesPlugin

[Greg Reddin <gr...@apache.org>]

On Dec 1, 2005, at 5:54 AM, <br...@tariffenet.it>  
<br...@tariffenet.it> wrote:

> I noticed that TilesRequestProcessor and TilesPlugin have  
> disappeared from
> Tiles standalone.

Yes, these are the components of Tiles that provide integration with  
Struts 1.2.x and earlier.  They were removed to break the dependency  
on Struts.

> What do you think of "reintegrating" at least TilesRequestProcessor?

We probably won't do that.  Standalone Tiles is not currently  
compatible with Struts versions prior to 1.3.   You can use Struts- 
tiles with those versions of Struts and the functionality will be the  
same.  As of 1.3 Tiles will be integrated using the chain-based  
architecture and the TilesRequestProcessor will no longer be needed.   
But, again, once this integration is written, the functionality will  
be the same as before.  The main question that remains is whether  
those components will be part of the Tiles project or part of Struts  
Action in some way.

Hope that clears it up a bit.
Thanks,
Greg




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org