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: [email protected] >> 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: [email protected] >>> 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. >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > >
