Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)

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

At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote:
>I think the presentation-tier-independent things about Tiles (like mapping
>forwards to definitions) should be built in to the core, so there isn't any
>such thing as a separate TilesRequestProcessor (or a separate chain or
>whatever).  In turn, this probably means we might need an API abstraction that
>alternative presentation tier technologies can use to integrate 
>themselves into
>the underlying support.

I managed to make Tiles work with struts-chain with a single 
pre-processor Command.  It basically looks up a tiles definition and 
replaces the ForwardConfig returned from an action with its own that 
has a path which RequestDispatcher to which can forward.

But it still uses the TilesPlugIn...  is that part of what you think 
should be moved up into the core?  Or do you think even the single 
Command is not the best future implementation?

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

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

Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)

["Craig R. McClanahan" <cr...@apache.org>]

Quoting Joe Germuska <Jo...@Germuska.com>:

> At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote:
> >I think the presentation-tier-independent things about Tiles (like mapping
> >forwards to definitions) should be built in to the core, so there isn't any
> >such thing as a separate TilesRequestProcessor (or a separate chain or
> >whatever).  In turn, this probably means we might need an API abstraction
> that
> >alternative presentation tier technologies can use to integrate 
> >themselves into
> >the underlying support.
> 
> I managed to make Tiles work with struts-chain with a single 
> pre-processor Command.  It basically looks up a tiles definition and 
> replaces the ForwardConfig returned from an action with its own that 
> has a path which RequestDispatcher to which can forward.
> 
> But it still uses the TilesPlugIn...  is that part of what you think 
> should be moved up into the core?  Or do you think even the single 
> Command is not the best future implementation?

I'll express my goals for this from a couple of perspectives:

>From the user's perspective, the fact that I'm using Tiles (or not) should not
require anything extra in the config (other than adding the definitions of the
tiles themselves, of course).  This probably implies that the configuration
data migrates into struts-config.xml as well.

>From the Struts developer perspective, I don't want to have to maintain two
request processors (or really even two command chains) -- the standard chain
should handle requests whether or not you reference a Tile.  So, if your
command that looks up the Tiles definition works on non-Tiles requests as well,
we can just build it in to the standard chain and call it good.


> Joe

Craig


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