Sorry I can't leave this alone. but every reason I have been given I have shown it can not work the way it was intended. to allow custom apps to give a a new main-decorator to an already existing app.
So either some more work has to be done on it, like what scott has proposed, Adopt a simple solution. rename the mainDecoratorLocation to applicationname-mainDecoratorLocation or add applicationname-mainDecoratorLocation to the context as well. maybe add some lines in the screens that say if applicationname-mainDecoratorLocation is not null use mainDecoratorLocation=applicationname-mainDecoratorLocation this would take care of backward compatibility I am wondering how many are actually using this feature and how. Chris Howe sent the following on 12/17/2007 4:44 PM: > It's already in the controller. > > <view-map name="main" type="screen" > page="component://content/widget/CommonScreens.xml#main"/> > You need to update the servlet that when it reads where to go, that it puts > that value of page into the context. Then your decorator can pull it out. > > ----- Original Message ---- > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 6:39:46 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > ah gee just found a flaw > the <viewmap>@page value into the context > does that go into the products or application controller. > will that create a backward compatibility problem? > > > > Chris Howe sent the following on 12/17/2007 4:28 PM: >> sorry, that should be page.startsWith("component://...") >> ----- Original Message ---- >> From: Chris Howe <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 6:16:14 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> You'll need to get put the <viewmap>@page value into the context and >> run a script in your main-decorator to determine the correct values >> >> if (page.like("component://partymgr") >> applicationMenuName = "Party"; >> elseif(page.like("component://product") >> applicationMenuName="Product"; >> etc >> parameters.put("applicationMenuName", applicationMenuName); >> >> then in your main-decorator, instead of having >> <set field="applicationMenuName" value="SetupMainMenu" > global="true"/> >> you will have >> <set field="applicationMenuName" >> vlaue="${parameters.applicationMenuName}"/> >> etc >> >> ----- Original Message ---- >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 6:07:08 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> 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. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> >> >> >> >> >> > > > > > > >