On Thu, 24 Mar 2005 16:07:24 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
> Martin Cooper wrote:
> > 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?
>
> I like where this is going...I would rather call it a "path handler".
> The role of this path handler would be to completely process the path,
> most likely returning output back to the user. The default handler
> could do a dispatch like it does now, but anyone could create their own,
> say, a PDF handler. I kinda have this built into stxx to allow
> completely control, in our case, of how the XML is used to generate
> output. I have used a PDF handler, XSLT, Velocity, SVG, and Cocoon at
> different times. Basically this "path handler" would to the view that
> the Action is to the controller, but more generic.
OK, I hadn't thought about taking it that far. ;-) So this thingumajig
would effectively do what PerformForward and PerformInclude do now (or
what used to be doForward() and doInclude() in the old request
processor), right? And the Tiles version would do more or less what
TilesPreProcessor does now?
I think that could be pretty cool, and unless I'm mistaken, it would
mean that plugging Tiles into Struts would require only (a) loading
the Tiles defs, and (b) registering a thiingumajig, both of which
would happen at startup time, and neither of which would involve
modifying the request processor. Maybe I'm missing something, but that
seems much cleaner than what we have now.
We'd need to figure out what kind of registration mechanism we want.
My first thought was to have Tiles call a registerThingumajig()
method, but I think we'd want to allow for control over the order in
which thingumajigs get a chance to play in the game. This seems like a
natural for Chain (give each thingumajig in the chain a chance to play
until one says "I got it"), but maybe I've got chain on the brain...
I've been calling this new thing a "thingumajig" here because I don't
think "path resolver" or "path handler" (or "path ${foo}") really
captures what it does. It's kinda like "OK, take it from here" as far
as Struts goes. I don't have any great ideas on what to call that
right now.
--
Martin Cooper
> Don
>
> >
> > --
> > 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]
> >
>
> ---------------------------------------------------------------------
> 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]
