my controller has
<!-- request handler for workeffort specific calls -->
<include
location="component://workeffort/webapp/workeffort/WEB-INF/controller.xml"/>
<!-- request handler for partymgr specific calls -->
<include
location="component://party/webapp/partymgr/WEB-INF/controller.xml"/>
<!-- request handler for marketing specific calls -->
<include
location="component://marketing/webapp/marketing/WEB-INF/controller.xml"/>
<!-- request handler for ordermgr specific calls -->
<include
location="component://order/webapp/ordermgr/WEB-INF/controller.xml"/>
<!-- request handler for accounting specific calls -->
<include
location="component://accounting/webapp/accounting/WEB-INF/controller.xml"/>
<!-- request handler for yahoo specific calls note this should be
the last one loaded -->
<include
location="component://yahoo/webapp/yahoo/WEB-INF/businessesnetworcontroller.xml"/>
the last one is mine.
I have a menu that has a target of
<menu-item name="partymgr"
title="${uiLabelMap.YahooPatrymgr}"><link target="partymgr"/></menu-item>
and in my controller I have
<view-map name="partymgr" type="screen"
page="component://party/widget/partymgr/PartyScreens.xml#findparty"/>
now if I don't have a mainDecoratorLocation defined in my web.xml for
<context-param>
<param-name>mainDecoratorLocation</param-name>
<param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
<description>The location of the main-decorator screen to use for
this webapp; referred to as a context variable in screen def XML
files.</description>
</context-param>
the screen for PartyScreens complains it can not find it.
Chris Howe sent the following on 11/21/2007 10:16 PM:
> Making the variable _name webapp specific would break the entire point of the
> variable.
>
> The variable is webapp specific (meaning it's defined by the webapp), but the
> variable _name is not. There are no partyMainDecoratorLocation variables,
> only mainDecoratorLocation.
>
> BJ, would it be possible for you to explain the webapp your developing. Off
> the top of my head, I'm unable to picture a scenario where wanting to
> maintain the decorator for two web applications is beneficial and would keep
> one sane. The only scenario that I can think of that even comes close is
> because of two different conventions being used in the screens of different
> components.
>
> ----- Original Message ----
> From: Jonathon -- Improov <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Thursday, November 22, 2007 12:03:18 AM
> Subject: Re: mainDecoratorLocation change to
> [applicationname]mainDecoratorLocation
>
> > Making the variable name webapp specific breaks the entire point of
> the
> > variable.
>
> The way the screen widgets are written now, the parameter
> "mainDecoratorLocation" is already
> webapp-specific.
>
> The key question is where we want to tie mainDecoratorLocation to. If
> it is specific to webapps,
> we tie it to controller.xml, so that views defined in a webapp will
> always use the decorator
> defined for that webapp. But if it is specific to an OFBiz component,
> then we tie it to a
> component config, like in component://party/config/SomeConfigFile.xml .
>
> Obviously, the screen widgets expect a correct value from
> ${parameters.mainDecoratorLocation}.
> Where should this be specified? If it is not webapp-specific, then does
> that imply screen widgets
> look for a global OFBiz-wide ${parameters.mainDecoratorLocation}
> somewhere?
>
> If the variable name "mainDecoratorLocation" wasn't webapp-specific, we
> wouldn't have this thread
> complaining about clashing or missing "mainDecoratorLocation"
> parameters when combining
> controller.xml(s) from multiple webapps.
>
> > For example, do you determine the variable from the included
> controller of
> > the request-map or from the view-map. You would likely choose the
> view. If
> > it's the view, how do you determine when that component has multiple
> webapp
> > as in product, etc/.
>
> I would choose neither the request map nor the view map. I suggest
> tying "mainDecoratorLocation"
> to controller.xml itself.
>
> If "mainDecoratorLocation" were view-specific, we would tie it to a
> view map.
>
> As the screen widgets are written now, they are webapp-specific.
>
> Jonathon
>
> Chris Howe wrote:
>> Hi Jonathon,
>>
>> Making the variable name webapp specific breaks the entire point of
> the
>> variable. I'm under the impression that most deployments of OFBiz
> use very
>> few of the applications as is, OOTB. Taking away the ability to
> change
>> the decoration of the application puts that much more burden on
> custom
>> applications to maintain a code base that is already maintained by
> the
>> community when all they want to do is extend and tweak subtle areas.
>>
>> The solution of further processing of the web.xml context-params in
> order to fill the
>> context starts to pull us away from the design of traditional web
>> applications. This has the effect of steepening the learning curve.
> In addition, there is too much ambiguity in deciding which
> mainDecoratorLocation would be chosen that I think it really would be best to
> determine it through a custom preprocessor so that one would end up with
> the desired results. For example, do you determine the variable from
> the included controller of the request-map or from the view-map. You
> would likely choose the view. If it's the view, how do you determine
> when that component has multiple webapp as in product, etc/.
>>
>>
>>
>> ----- Original Message ----
>> From: Jonathon -- Improov <[EMAIL PROTECTED]>
>> To: [email protected]
>> Sent: Wednesday, November 21, 2007 10:56:14 PM
>> Subject: Re: mainDecoratorLocation change to
> [applicationname]mainDecoratorLocation
>> I think BJ's method is fine. It's the only way to couple the
>> webapp-specific parameter
>> "mainDecorationLocation" to a particular webapp, and to decouple it
>> from the single global servlet
>> context (single to a webapp).
>>
>> Say a parent webapp includes the controller.xml of a child webapp, we
>> use "parent" and "child" so
>> it's easy for me to write here.
>>
>> When we <include> the child's controller.xml from the parent webapp,
>> the servlet context is still
>> the parent's, not a mix of 2 webapps. There will be only one
>> "mainDecoratorLocation" parameter for
>> all the widgets listed in both controller.xml(s).
>>
>> When we need to process the views (or widgets) specified in the
> child's
>> controller.xml, we need to
>> do something extra. Those views require a specific
>> "mainDecoratorLocation" value in order to work,
>> say "component://child/widget/MainDecorScreens.xml". The parent will
>> need to play by those rules,
>> and create "mainDecoratorLocation" with that expected value for the
>> child's views to work.
>> Specifically, I mean "for the child's views to work in the parent's
>> servlet context".
>>
>> The problem comes when the parent also has its own
>> "mainDecoratorLocation", say
>> "component://parent/widget/MainDecorScreens.xml". Then there is a
>> clash. Because the 2 webapps'
>> widgets operate in a single servlet context, there can only be one
>> parameter
>> "mainDecoratorLocation" for both webapps.
>>
>> BJ's method is the only quick fix there is. Decouple
>> "mainDecoratorLocation" from the global
>> servlet context, and encapsulate that attribute together with the
>> widgets that require that
>> particular attribute with a particular value.
>>
>> That means changing all widgets to point to say
>> "<webapp-name>:mainDecoratorLocation". Another
>> solution could be to add a new attribute to <decorator-screen>, like
>> "param-location" which
>> automatically hunts for a parameter named
>> "<webapp-name>:mainDecoratorLocation". So a value of
>> "myDecoratorLocation" might prompt the widget engine to look for a
>> parameter named
>> "<webapp-name>:myDecoratorLocation".
>>
>> That is a simple fix.
>>
>> For a better fix, we need to truly decouple "mainDecoratorLocation"
>> from the global servlet
>> context (web.xml), and put it into the controller.xml. The widget
>> engine could look in the
>> controller.xml for a variable "mainDecoratorLocation" every time it
>> processes a screen widget.
>> That would ensure perfect re-usability of any included widgets
>> (included with a controller
>> <include>), without the need to meddle with passing in the expected
>> "mainDecoratorLocation" for
>> those included widgets.
>>
>> Some changes to ConfigXMLReader, RequestManager and ControlServlet
> may
>> be required.
>>
>> Hope that makes sense.
>>
>> I love how OFBiz already has many powerful "clean extension"
>> mechanisms, much like object-oriented
>> programming and sub-classing. This "mainDecoratorLocation" thing may
> be
>> a good area to work on.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> so far you and I are on the same page.
>>> I thinks the confusion is, I am not defining a mainDecoratorLocation
>>> for my application. So this is not about how to use
>> ainDecoratorLocation
>>> in my web.xml for my widgets.
>>> the web.xml has been used to provide context for widget's
>>> mainDecoratorLocation, which as you point out is a component.
>>>
>>>
>>> here are the steps:
>>> include another controller in your apps controller.
>>> Now the mainDecoratorLocation is defined in the web.xml of the
>> included
>>> controller, but not mine.
>>> so if I don't delcare a mainDecoratorLocation in my web.xml I get an
>>> error, about the mainDecoratorLocation not being found, when I
> access
>>> the included controls widget.
>>> If I define a mainDecoratorLocation in my web.xml that has the path
>> for
>>> one of the application that is included in my controller, it works
>> fine.
>>> But just for that application.
>>> This lets me only define one mainDecoratorLocation for all included
>>> controllers.
>>> so I can not define a mainDecoratorLocation in my web.xml for each
>>> application with the path defined in the application web.xml.
>>>
>>>
>>>
>>> Chris Howe sent the following on 11/21/2007 6:39 PM:
>>>> No, the feature of mainDecoratorLocation is the webapp being called
>> defines the default value of mainDecoratorLocation. You should be
> able
>> to run a pre-processor to override the value that is found in the
>> called webapp's web.xml file.
>>>> It may help to identify here the difference in terminology that is
>> used. There's a component and a web application. The web
> application
>> is what is generally under the webapp folder and does not include
> the
>> widgets. The widgets (form, screen, tree, menu) belong to the
> component,
>> not the webapp.
>>>> The controller controls the web application along with the context
>> provided by the web.xml definitions. So, if I have webapp: myApp,
> the
>> context should be provided by the web.xml file in the web
> application
>> myApp, at least by default. Simply because you are including
> elements
>> from another document does not mean you should change what provides
> the
>> default context.
>>>> webapp/myApp
>>>> /WEB-INF
>>>> /controller.xml <--Controls
>> web application myApp
>>>> /web.xml <--provides
>> context for web application myApp
>>>> ----- Original Message ----
>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>> To: [email protected]
>>>> Sent: Wednesday, November 21, 2007 7:59:52 PM
>>>> Subject: Re: mainDecoratorLocation change to
>> [applicationname]mainDecoratorLocation
>>>> If i understand you correctly the path to mainDecoratorLocation
>> should
>>>> be the same for all apps.
>>>> however if the path is in the application should it not be
>> distinguish
>>>> for that application?
>>>>
>>>> Chris Howe sent the following on 11/21/2007 5:50 PM:
>>>>> The "problem" that you're having is the exact feature that is
>> created
>>>> by mainDecoratorLocation. Appending [applicationname] breaks that
>>>> feature. Are you unable to override
>> parameters.mainDecoratorLocation
>>>> through a preprocessor or by another means?
>>>>> ----- Original Message ----
>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>> To: [email protected]
>>>>> Sent: Wednesday, November 21, 2007 7:02:18 PM
>>>>> Subject: mainDecoratorLocation change to
>>>> [applicationname]mainDecoratorLocation
>>>>> when including other controllers, the context for
>>>> mainDecoratorLocation
>>>>> has to be defined in the web.xml of the home controller location.
>>>>>
>>>>> this causes a problem when all the application use
>>>>> mainDecoratorLocation.
>>>>>
>>>>> so would like to propose that the mainDecoratorLocation is used
> for
>>>> the
>>>>> framework/common/webapp/
>>>>>
>>>>> and preappend the application name to mainDecoratorLocation
>>>>> ([applicationname]mainDecoratorLocation) in the applications
>>>> web.xml.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
>
>
>
