this should be brought over when the multiple example is done. http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21
BJ Freeman sent the following on 12/19/2007 4:15 PM: > I want to give Chris Howe a big thanks for taking the time to show me my > errors. > he has a single app which does not take in to some other criteria for > accessing multiple apps. > so He did one for multiple apps. > I plan to submit the basic parts as a template patch unless someone > would rather have it in an Myapp-example > > I am incorporating most of what Chris showed me in the setup app. > > > > Jonathon -- Improov sent the following on 12/19/2007 1:06 AM: >> Also in response to BJ's "been through this umteem times"... >> >> The idea is to provide neat encapsulation for screen widgets and their >> required "mainDecorator" params. Have a clean wrap around the 2. >> >> When including (<include>) controller.xml of a component say "party", we >> would also be including all the <view-map>s. >> >> Many of those <view-map>s point to screen widgets that require a >> particular "mainDecorator" to work. >> >> Consider that your custom app includes controller.xml files from more >> than one component. Each component will require its own "mainDecorator". >> >> Ideally, we would want to be able to reuse all <view-map>s and screen >> widgets from all included components, without having to individually >> specify which "mainDecorator" to use for which <view-map>. >> >> BJ's suggested solution is a quick hack and alternative to the ideal >> solution. Something we may be able to develop quickly without desiging a >> full-blown space station. >> >> Jonathon >> >> Chris Howe wrote: >>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > >
