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