I am thinking along this line in our portal implementation. Each tile is a portal service that has its own service controller to do data processing. There is a main portal body where messages and presentations are displayed. Errors and messages in all portal services will be catched and a new message that can use Struts error mechanism is written to a bodyMessages in the request scope. The portal body tile will be assenbled last. The jsp of this portal body will have the first section to write all messages from bodyMessages of the request scope and then its own presentation. This is similar to the current signOnForm with error messages displayed at the top. The logic will work only when the portal body tile can be assembled last to collect all messages in the request scope bodyMessages. What do you think Cedric and how to guarantee that the portal body tile will be assembled last?
BaTien -----Original Message----- From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 20, 2003 9:24 AM To: Struts Users Mailing List Subject: Re: TilesAction and Controller David Graham wrote: > Cedric, > I thought the main point of the controller was to allow you to attach > data preparation to the tile instead of in every action that may > forward to that tile. That is a very useful feature! All of my (and > many others) data preparation involves accessing a database so error > handling must be considered. > > Do you think it would be a useful enhancement to hook the Tiles > controllers into the exception handling mechanism? You probably know > better than I if this is doable. It will be a useful enhancement to provide an exception handling mechanism to tiles controllers. For now I have no idea on what could be the proposed syntax. I would like to keep the syntax simple. The problem is that actually you describe a definition (a view renderer) and you can associate a controller to it. If the controller fails, what should we do ? You certainly want to use another view. Should we specify an exception handler forwarding to a tile definition or an url inside the current definition description ? Another point about exceptions is: what should we do when an exception occur inside a tile ? Do we provide a similar mechanism than for controllers ? Any ideas are welcome. Once we know exactly the behavior we want we will be able to implement it. Cedric > > > Thanks, > Dave > > >> When you use controllerUrl, Tiles do a RequestDispatcher.include() >> of your url. Any processing done from this include is taken into >> account. However, the goal of controllerUrl is to be able to >> associate a tiles controller which should normally only preprocess >> data (no rendering). So, you should avoid the use of ActionForward of >> forwards with an action used as tiles-controller. >> >> If you want to write a controller having different rendering views >> depending of errors/computation, you should better write a struts >> action used as controller, and do some forwards to tiles definition. >> >> The controller concept of Tiles is very basic: just one method >> called before the tile rendering; no error mechanism. Struts allow >> witting complex controllers as Actions. >> >> Cedric >> > > _________________________________________________________________ > Tired of spam? Get advanced junk mail protection with MSN 8. > http://join.msn.com/?page=features/junkmail > > > --------------------------------------------------------------------- > 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]
