On Apr 25, 2006, at 6:19 PM, Michael Jouravlev wrote:
On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
According to the APIs, it is actually one Controller per Tile, not
one
Controller per page ... doesn't that give you (Michael) the hook
you'd need
to grab the dynamic data for each fragment?
I guess it does. But how is this better/different than simply
including Struts actions or any other resources?
Also, can I submit to a particular controller? Does a controller
have URL?
Actually there is the controllerUrl parameter that will allow Tiles
to submit a request to an URL as a controller. IIRC, the purpose of
this is to invoke a Struts action. The use case you describe is not
unheard of. But to me it can be problematic. As another poster
pointed out, I would not want my app to be invoking the entire Struts
request processing chain 2 or more times in one request. Besides
that, there's the mental overhead of having to remember that certain
actions are "Tiles pseudo-controller actions" that just make app
maintenance difficult. But again, the support is there and I suppose
it was added for a reason :-)
The truth is I haven't fully put Tiles through its paces and I don't
nearly claim to understand everything it was designed to do or is
capable of doing. I'm trying to be careful to not present things as
fact that I can only speculate on. But I've used Tiles in several
apps and in every case I pulled the calls to actions as prerender
steps and replaced them with controllers. The controller class has
access to everything the action does. About the only thing a
controller cannot do is return a forward to an alternative location.
But it does have access to the Tiles context and can set or change
values. I agree that one controller per Tiles definition creates a
coupling with the definition and its attributes. So if one of the
definition's attributes is a JSP page with dynamic content you can
manage the dynamic content with a Tiles controller, but that creates
an undesirable coupling (a coupling that, IMO is not resolved by
using an action instead of a controller). I might like to have a
prerender controller for each attribute as well as for the whole
definition. This is a case where I can see the value of JSF's
component model.
If I understand you correctly you're wanting each part of a composite
view to have a controller class invoked before rendering the view. I
don't think tiles directly supports this. It does allow you to
execute a controller that has effect over the entire view. I guess
the rationale is that if you are working at the composite view level
and making changes there you can also manage changes to the
controller class. But it certainly introduces complications if a JSP
arbitrarily includes another JSP that depends on dynamic data. So...
if I'm changing my tile definition to add an advertisement fragment
then I can go into the controller class to deal with the data
requirements. Not a perfect solution, but doable. I'd argue that it
is better than invoking a Struts action to do the same thing. I just
don't want the overhead and potential for error of calling another
action in that context.
There are other options. You could implement a custom tag as part of
your advertisement fragment that handled the dynamic parts in a self-
contained way. You could hack tiles by specifying your
advertisement fragment as a definition in its own right and using the
tiles:insert tag to include it. Then the advertisement fragment
becomes a definition with no attributes and you have to use some
weird code in a page somewhere to include it, but it's not too
terrible. So, there are options.
I guess I have to go read the docs one more time. Please excuse me for
heating up the discussion without checking the facts.
I don't think it's heated at all. Sounds like you're just trying to
understand. I'm sorry if this response seems disjointed. I'm trying
to bring back up all the stuff I used to do :-)
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
