Chris Howe sent the following on 12/17/2007 4:09 PM: > be sure to define the mainDecoratorLocation in the web.xml as > component://myapp/widget/CommonScreens.xml yes > >>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. you have not looked at the current main-decoroators here is one from party 1) defines Java scripts to use 2) defines <set field="activeApp" value="partymgr" global="true"/> So I can only define one <set field="activeApp" value="setup" global="true"/> so when partymgr looks for the active app it will go to setup instead of patrymgr. This mean I have a lot of overhead in maintainence instead of just using the partymgr as is.
or like <set field="appheaderTemplate" value="component://order/webapp/ordermgr/includes/appheader.ftl" global="true"/> > > ----- 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. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >