so far you and I are on the same page. I thinks the confusion is, I am not defining a mainDecoratorLocation for my application. So this is not about how to use ainDecoratorLocation in my web.xml for my widgets. the web.xml has been used to provide context for widget's mainDecoratorLocation, which as you point out is a component.
here are the steps: include another controller in your apps controller. Now the mainDecoratorLocation is defined in the web.xml of the included controller, but not mine. so if I don't delcare a mainDecoratorLocation in my web.xml I get an error, about the mainDecoratorLocation not being found, when I access the included controls widget. If I define a mainDecoratorLocation in my web.xml that has the path for one of the application that is included in my controller, it works fine. But just for that application. This lets me only define one mainDecoratorLocation for all included controllers. so I can not define a mainDecoratorLocation in my web.xml for each application with the path defined in the application web.xml. Chris Howe sent the following on 11/21/2007 6:39 PM: > No, the feature of mainDecoratorLocation is the webapp being called defines > the default value of mainDecoratorLocation. You should be able to run a > pre-processor to override the value that is found in the called webapp's > web.xml file. > > It may help to identify here the difference in terminology that is used. > There's a component and a web application. The web application is what is > generally under the webapp folder and does not include the widgets. The > widgets (form, screen, tree, menu) belong to the component, not the webapp. > > The controller controls the web application along with the context provided > by the web.xml definitions. So, if I have webapp: myApp, the context should > be provided by the web.xml file in the web application myApp, at least by > default. Simply because you are including elements from another document > does not mean you should change what provides the default context. > > webapp/myApp > /WEB-INF > /controller.xml <--Controls web > application myApp > /web.xml <--provides context > for web application myApp > > > ----- Original Message ---- > From: BJ Freeman <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, November 21, 2007 7:59:52 PM > Subject: Re: mainDecoratorLocation change to > [applicationname]mainDecoratorLocation > > > If i understand you correctly the path to mainDecoratorLocation should > be the same for all apps. > however if the path is in the application should it not be distinguish > for that application? > > Chris Howe sent the following on 11/21/2007 5:50 PM: >> The "problem" that you're having is the exact feature that is created > by mainDecoratorLocation. Appending [applicationname] breaks that > feature. Are you unable to override parameters.mainDecoratorLocation > through a preprocessor or by another means? >> ----- Original Message ---- >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: [email protected] >> Sent: Wednesday, November 21, 2007 7:02:18 PM >> Subject: mainDecoratorLocation change to > [applicationname]mainDecoratorLocation >> >> when including other controllers, the context for > mainDecoratorLocation >> has to be defined in the web.xml of the home controller location. >> >> this causes a problem when all the application use >> mainDecoratorLocation. >> >> so would like to propose that the mainDecoratorLocation is used for > the >> framework/common/webapp/ >> >> and preappend the application name to mainDecoratorLocation >> ([applicationname]mainDecoratorLocation) in the applications > web.xml. >> >> >> >> >> > > > > > >
