good point. #1 so I will not put this to sleep and do it for my releases until, as you say it become a problem
However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: > Note: I'm not saying that prefixing the variable is a bad solution I'm just > throwing out the downsides of it > 1) The use case you present should not be encouraged. The opportunity for > conflicting requests/views between multiple controllers will drive you bat > crazy with unexpected results. The intent of the <include> element is to > modularize commonly used requests/views. Throwing everything in a bag and > hoping you pull the expected result/view out is kind of dangerous. Absent a > compelling use case, movement towards an external widely adopted standard, or > utilizing more generic practices it's difficult to overcome the backward > compatibility issue. > > 2) if you were to address the backward compatibility issue by making the > mainDecoratorLocation the default if [prefix]-mainDeocratorLocation were > null, I believe that you would be moving away from the Java Servlet spec by > processing the context parameter. I could certainly be wrong. I'm no expert > on such things. > > ----- Original Message ---- > From: BJ Freeman <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, December 17, 2007 4:27:19 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > It seems a lot of work for simple solution > how about app-mainDecoratorLocation > then if someone want to use their own decorator it will still work. > they just define each app-mainDecoratorLocation in their web.xml > it either points to the original location or their customer decorator. > > > > > > > >
