At 2:37 PM -0500 7/28/05, Greg Reddin wrote:
On Jul 28, 2005, at 1:50 PM, Joe Germuska wrote:
At 1:19 PM -0500 7/28/05, Greg Reddin wrote:
Actually, I was thinking that if you had a standalone Tiles, you
wouldn't need bits of glue; wouldn't you just install Tiles as a
servlet in the webapp which mapped to something like "*.tiles", and
then in Struts, you'd just use paths like "/my/view.tiles" instead
of "/my/view.jsp" or a literal tiles definition name? Maybe
struts-tiles will wither away?
That's basically going back to Tiles before Struts integration. I
guess, for backwards compatibility concerns in the 1.* path, the
TilesPlugin and TilesRequestProcessor would continue.
I don't know the history; I thought Tiles was written to integrate with Struts!
The TilesRequestProcessor is obsolete in Struts 1.3 -- that is, it
will still work, but if you use it, you will not be able to take
advantage of the ComposableRequestProcessor and some new features
have only been implemented using that (such the per-action-mapping
commands).
TilesPlugin is still the appropriate way to bootstrap a constellation
of tiles definitions for use by Struts, whether you're using the
ComposableRequestProcessor with the TilesPreProcessor command or
using the TilesRequestProcessor
But yes, we won't rip out those classes required for backwards
compatibility without a decent advance warning/deprecation period.
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]
