Yet another reason frames are evil. The “normal” pattern for a Struts/Tiles app is that your application contains links that point to Struts actions. The action executes, and maps the result to an ActionForward that points to a Tiles template. The Tiles template then pulls in the pieces of the view (header, menu, content, etc) and sends the result to the user.
Now imagine the same thing with a frames application. In frames, the browser first pulls down the frameset in an HTML document, then reads from the HTML document where to retrieve the contents of the individual frames, in separate requests, from different URLs. So if you call the Struts action and then forward to the Tiles template, whatever data you may have stored in the request is completely useless – the request the data was placed in was used to grab the frame layout, and this new request to load your content doesn’t contain the information you wanted. (This does assume that you reload all frames with each request.)
The other option is similarly lame, more complex, and also not functional. You essentially have to split your application logic into 2 categories, data you want to read, and data you want to submit. On a submit, you still submit directly to a working struts action. If you want to populate data into the view, however, your initial Struts action has to be a forward to a Tiles definition, and you have to make the tile region point to the Struts action that fetches the data, then have that forward point to the actual JSP to be loaded. In this case, if you want to have an interaction that submits data and then includes information from that interaction on the response screen, you have to find a way to pass that data around rather than putting it in a request.
Frames were broken the day they arrived. The way they completely hose dynamic web pages is a further indictment of their uselessness.