be sure to define the mainDecoratorLocation in the web.xml as component://myapp/widget/CommonScreens.xml
>From there the only app specific stuff is the whether it's including >leftbar/rightbar/etc. You will need to define those basic ones as well. ----- Original Message ---- From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:59:58 PM Subject: Re: mainDecoratorLocation was Include of controllers 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. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >
