Am Sonntag, 3. September 2006 21:01 schrieb Nikola Banovic: > Chris, > > I'm facing the same problems as you are. Please take a look at my post > from 08/31/06: "[magnolia-user] RequestDispatcher forward problems in > Magnolia 2.1.5 public instance". You'll notice the similarity :). >
Yes, I see quite similar. I am however using 3.0 rc2 but I don't think that matters for this issue. > My thoughts on your questions: > > 1. I'm trying to understand if forwards bypass Magnolia's filter > mechanism. I added <dispatcher>REQUEST</dispatcher> and > <dispatcher>FORWARD</dispatcher> elements to all the <filter-mapping> > elements in my web.xml file to make sure that the filters get called. They don't so much by-pass it as happen after it. The first request comes in and the filtering finds that it matches a handle in the website workspace. So Magnolia does its work of looking up the template and configuring the context and letting the template deal with the response. Forwards triggered by the template do not come through the 'front door' again. Therefore Magnolias filtering is not done, and the path is not recognized/treated as a Magnolia handle request. So we get a 404 error. This is why a redirect works. The redirect does go through all the filtering again, and therefore is recognized/treated as a Magnolia page request. But as you point out, through the redirect you now lose all your state information. And we don't always want to redirect. > > I'm also going to try to recompile Magnolia code and go step-by-step > thru the process in a debug mode to better understand what is going on. > > 2. I agree with you. We can't always use redirects. > > 3. I think this is a problem with Struts and a lot of people ask this > question on the Struts mailing list (regardless of Magnolia). I hope we > are going to be able to create more dynamic action mappings with Struts > 2, but until then I don't think we can do much about it. I don't know much about struts, but I had hoped it would be possible to generate the struts action map based on the content repository. > > The approach we took was to let Magnolia handle all the pages that do > not require communication with the business layer with its own > "controller" mechanism. However if there is a user interaction thru > forms then we submit the forms to Struts actions which then in turn > forward the request to the business layer. Once the business layer is > done processing we redirect or forward to a Magnolia page. > > So basically we use Magnolia just like we would use any other "view" > technology, except that we don't have Struts action mappings for every > page on the site. > > 4. This sounds like rewriting Magnolia :). Yeah, my fourth suggestion was really just for sake of completeness. I don't think it is a good idea at all. We're interested in how to make the action mapping dynamic. Struts sort of assumes requests for one of a fixed number of pages which then reference dynamic content. Magnolia on the other hand assumes requests for one of a variable number of pages. So I think there is a basic conflict here. Dynamic configuration of the action based on existing pages would be a better solution. Or forwards that don't side step filtering. Or some sort of magnolia oriented forward, that reactivates the filtering code and does the right thing with handles. None of it looks very attractive. Chris ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
