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.
Agreed.
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.
Yeah, that could work but that seems like a hack too. In the cast of stxx, the paths are not physical paths. For example, I'll forward to "simple/foo.dox" which matches the "simple/*" pipeline. I suppose I could make that "/WEB-INF/simple/foo.dox" then match the additional prefix, but that seems like an ugly hack and quite confusing.
Still, I'm not very helpful as I don't have a good solution. The stxx chain adaption I'm using doesn't account for exceptions thrown.
Don
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
