On Thu, 24 Mar 2005 17:37:05 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 1:23 PM -0800 3/24/05, Don Brown wrote: > >I've kept an eye on this thread as stxx uses a similar integration > >strategy as Tiles. I considered using the Velocity approach, but > >decided it wasn't ideal as it exposed paths to client that didn't need > >to be exposed. I like the strategy of hiding alternate view > >processing within Struts as, again, it keeps those special urls hidden > >and secure. I use this approach for both Tiles and the Cocoon plugin. > > I see your point, but I still think needing to explicitly configure > the TilesPreProcessor for two different view contexts is a hack. It > has the bad-code smell that makes me think that we need to > re-engineer something -- even if I don't know what.
Perhaps what we need is the concept of a "path resolver" that takes a virtual path and turns it into a real path. The default would be passthrough, but it would be pluggable in some way so that Tiles (or stxx or whatever) could register with it and be given a chance to resolve, for example, a tile name to a real path. Then we just make sure that anywhere we're about to do a forward (or an include), we invoke the path resolver first. Does that make any sense? -- Martin Cooper > If you put your .tiles paths all under /WEB-INF/ then wouldn't you > achieve the same kind of protection that people who put JSPs there > do? It seems like that should work, although that's pure > speculation. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
