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. >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >
