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.
