here is an exmple <set field="applicationMenuName" value="SetupMainMenu" global="true"/> <set field="applicationMenuLocation" Value="component://setup/widget/setup/MainSetupMenus.xml" global="true"/>
now I can only setup that up for one menu so how do I set that up for each menu for each app? BJ Freeman sent the following on 12/17/2007 3:59 PM: > Oh.. well I did. > and got all sorts of errors because I has not included what that > application expected for its decorator. > > and I could not find a way to use the app specific information for each > app in my main-decorator. > > which started me down the road to app-mainDecoratorLocation > > Chris Howe sent the following on 12/17/2007 3:50 PM: >> Woops...pressed the send button by mistake. >> >> Make your own decorator in /myapp/widget/CommonScreens.xml >> >> create a main-decorator and a global decorator and use modify to your >> heart's content >> >> ----- Original Message ---- >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 5:33:01 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> so what is the approach that works? >> >> >> Chris Howe sent the following on 12/17/2007 3:26 PM: >>> That's what I wasn't understanding. Your approach fails with that >> problem. The approach others have been using for the last two years does >> not. I thought you were asserting that both approaches fail. >>> ----- Original Message ---- >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 5:21:55 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> been through this umteem times. >>> sigh >>> this is not the case for ftl files only widgets. >>> >>> I access a screen widget in x-app from my custom app. >>> that screen has a decorator which eventually looks up >>> mainDecoratorLocation to get the main-decorator >>> >>> so we are back to defining the mainDecoratorLocation. >>> I can only define one mainDecoratorLocation in my web.xml >>> so if I call another screen widget in y-app the information for the >>> x-app main-decorator will be passed causing other problems. >>> >>> So there is no way a mainDecoratorLocation can be globally declared >> to >>> use more than one application screen widgets from the custom app >>> So there is no use for using the mainDecoratorLocation outside that >> app >>> >>> Chris Howe sent the following on 12/17/2007 3:11 PM: >>>> I'm not sure I understand what you mean by access multiple apps from >>> a custom app. When you have a custom app, there is no notion that >>> included screens, called screens, included controllers, etc have a >> context >>> of ownership. The custom app is simply locating snippets of xml. >>> Nothing more. You can call snippets from one component or two or >> five, it >>> doesn't matter. It only matters if you attempt to assert a context >> of >>> ownership; that calling a controller from the party controller has >> some >>> meaning about associated party variables or contexts. >>>> ----- Original Message ---- >>>> From: BJ Freeman <[EMAIL PROTECTED]> >>>> To: dev@ofbiz.apache.org >>>> Sent: Monday, December 17, 2007 4:57:18 PM >>>> Subject: Re: mainDecoratorLocation was Include of controllers >>>> >>>> >>>> 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: dev@ofbiz.apache.org >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > >