I'm not sure what you mean by "changing" a tiles definition.
Basically a tiles definition is a singleton object, shared by all threads in the server, like a Servlet. Modifying this objet in an ActionListener, i.e. for the purpose of fulfilling a single request, doesn't sound safe. However, you can: - design a tiles definition so that it uses a request/session attribute. You can set the value of the attribute in the ActionListener and the tiles-def will pick it up (either display its value or include another JSP/Tiles-def/Servlet based on its value). - create a new tiles definition at runtime that extends the old one, and put whatever value you like in its attributes. But why should you want to do this on a per-request basis? I cannot think of any use case right now...
Additionally, adopting a more philosophical point of view, I believe your MVC2 controller should not be aware of the structure of its view. You should not have to modify the backing bean if you decide to render the view using Plain Old JSP or Facelets instead of Tiles, or if you want to redesign your Tiles Definition (put the menu on the top of the page, when it was on the left). Therefore I believe that referencing Tiles in an ActionListener or Backing Bean is not a good programming practice. It would be better to reference a request attribute (or even better: a Backing Bean property) both in the ActionListener and the Tiles Definition. It would keep both technologies unaware of each other, and I believe things would evolve more smoothly afterwards.
What do you think ? Nick. Jacek Woźniczak a écrit :
I'm still curious how to integrate Tiles runtime composition into JSF environment, for example change tiles definition "on the fly" in actionListener method. Theoretically:Tiles Servlet runs after JSF servlet, so if I change tiles definition in ActionListener method (which run in the InvokeApplication phase) this modification should be reflected. Am I right?
