mainDecoratorLocation change to [applicationname]mainDecoratorLocation

[BJ Freeman]

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.

[cjhowe]

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

[BJ Freeman]

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

[cjhowe]

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

[BJ Freeman]

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

[jonwimp]

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

[cjhowe]

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

[BJ Freeman]

I am willing to put the mainDecorationLocation somewhere besides the
web.xml is it is a component item.
So where should it be put so it is reference as a component.
maybe put it in the controller like the view screens of components?
that way it is alway specific to that component.

I don't see how a preprocessor in my controller would work. it if does
not know where the mainDecorationLocation is associated with.


Chris Howe sent the following on 11/21/2007 9:28 PM:

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

[jonwimp]

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

[jonwimp]

Putting it to a component will limit the screen widgets to their respective components, so they
can't be used in pages outside of those components. But I think it'll still work. At the moment, I
can't think of how or why we would want a particular screen widget using different decorators in
different contexts. Well, I can, but I'd rather not have to explain any complex scenarios now.

Putting it to the controller.xml (ie to the webapp) could be more flexible.

A preprocessor won't work, unless you go the extra mile to read the web.xml in the included
webapp's controller.xml . Even then, you face the issue of clashing mainDecoratorLocation values
between the parent and the child webapp.

Jonathon

BJ Freeman wrote:

> I am willing to put the mainDecorationLocation somewhere besides the
> web.xml is it is a component item.
> So where should it be put so it is reference as a component.
> maybe put it in the controller like the view screens of components?
> that way it is alway specific to that component.
>
> I don't see how a preprocessor in my controller would work. it if does
> not know where the mainDecorationLocation is associated with.
>
>
> Chris Howe sent the following on 11/21/2007 9:28 PM:
>> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>>
>
>

[cjhowe]

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

[jonwimp]

About the only thing I can think of now is this. Showing on request path "/partymgr/control/" the
exact same screen that should reside on "/ordermgr/control/".

Yeah, BJ, what is your scenario?

Far as I can see in OFBiz now, the controller.xml <include> is only used to clone another webapp.
Because clones should be the same (except for webstoreid), they also use the exact same
mainDecoratorLocation (specified twice, once in original webapp's web.xml and once in clone's).
Clones won't see a clash in 2 different mainDecoratorLocation values.

Jonathon

Chris Howe wrote:

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

[BJ Freeman]

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

[cjhowe]

Why are you opposed to running 6 separate webapps under a component?
mycomponent/webapp
                                   /myworkeffort
                                   /mypartymgr
                                   /mymarketing
                                   /myordermgr
                                   /myaccounting

                                   /myyahoo


I can almost guarantee you'll drive yourself insane with request-maps and view-maps overriding each other and giving unexpected results.

----- Original Message ----
From: BJ Freeman <[hidden email]>
To: [hidden email]
Sent: Thursday, November 22, 2007 1:58:37 AM
Subject: Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation

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

[BJ Freeman]

if that is your answer to the problem, not much help.
:)


Chris Howe sent the following on 11/22/2007 12:10 AM:

> Why are you opposed to running 6 separate webapps under a component?
> mycomponent/webapp
>                                    /myworkeffort
>                                    /mypartymgr
>                                    /mymarketing
>                                    /myordermgr
>                                    /myaccounting
>
>                                    /myyahoo
>
>
> I can almost guarantee you'll drive yourself insane with request-maps and view-maps overriding each other and giving unexpected results.
>
> ----- Original Message ----
> From: BJ Freeman <[hidden email]>
> To: [hidden email]
> Sent: Thursday, November 22, 2007 1:58:37 AM
> Subject: Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation
>
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>

[BJ Freeman]

I have some screens I handle differently.
I have kept from going crazy by calling the ones and let the controller
in that app handle it.
I have not had any problems so far, except for mainDecoratorLocation

and from what I am reading it should not be where it is to follow best
practices.

question is where to put it.



Chris Howe sent the following on 11/22/2007 12:10 AM:

> Why are you opposed to running 6 separate webapps under a component?
> mycomponent/webapp
>                                    /myworkeffort
>                                    /mypartymgr
>                                    /mymarketing
>                                    /myordermgr
>                                    /myaccounting
>
>                                    /myyahoo
>
>
> I can almost guarantee you'll drive yourself insane with request-maps and view-maps overriding each other and giving unexpected results.
>
> ----- Original Message ----
> From: BJ Freeman <[hidden email]>
> To: [hidden email]
> Sent: Thursday, November 22, 2007 1:58:37 AM
> Subject: Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation
>
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>

[jonwimp]

Your use case seems valid.

In a nutshell, you're simply cloning a webapp, and then extending it with your own requests and
features.

That's great. It means you won't have to repeat the scores of request maps in the webapp you're
cloning.

That said, it's pretty scary to see 6 webapps rolled into 1 (your custom webapp, where you extend
original OFBiz codes). Still, it's just a matter of splitting up those 6 webapps into 6 custom
webapps, something you may do when you have time.

I can see where having the mainDecoratorLocation parameter tied to the webapp (controller.xml) can
be useful. But I find it hard to vote for making this extension to the OFBiz framework. You can
simply extend webapp "workeffort" with "myworkeffort", and use the same mainDecoratorLocation that
"workeffort" uses. In short, there's a simple and useful workaround now.

Over time, it will be nice to be able to clone "workeffort" and let it use its own
mainDecoratorLocation, while my extensions in "myworkeffort" use a different
mainDecoratorLocation. No clash.

I think I've worn myself out trying to explain technical issues in technical terms. Let me try an
analogy. So, for the last time...

Customer: "I want a hamburger."

Cashier: "What's the code to activate my POS machine?"

Customer: "I don't know?"

Cashier: "Sorry, you need to know, or no hamburger for you."

Customer: "Don't you know?"

Cashier: "I know it for that other POS machine, not this one. You're ordering a hamburger from
this one, so I can't serve you unless you got the code!"

Customer: "I want to talk to your manager."

Cashier: "Alright. He'll probably ask you write some codes to read the web.xml file in that other
POS machine and retrieve the code (mainDecoratorLocation) there, so be prepared."

Jonathon

BJ Freeman wrote:

> I have some screens I handle differently.
> I have kept from going crazy by calling the ones and let the controller
> in that app handle it.
> I have not had any problems so far, except for mainDecoratorLocation
>
> and from what I am reading it should not be where it is to follow best
> practices.
>
> question is where to put it.
>
>
>
> Chris Howe sent the following on 11/22/2007 12:10 AM:
>> Why are you opposed to running 6 separate webapps under a component?
>> mycomponent/webapp
>>                                    /myworkeffort
>>                                    /mypartymgr
>>                                    /mymarketing
>>                                    /myordermgr
>>                                    /myaccounting
>>
>>                                    /myyahoo
>>
>>
>> I can almost guarantee you'll drive yourself insane with request-maps and view-maps overriding each other and giving unexpected results.
>>
>> ----- Original Message ----
>> From: BJ Freeman <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, November 22, 2007 1:58:37 AM
>> Subject: Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation
>>
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> 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.
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>

[BJ Freeman]

Just to clarify, I consider my app an overlay.
I am not moving any code from the trunk or ver 4.0 into my app.
for instance I am merging two ftl in Ordermgr.
I do create a widget but the ftl are till in ordermgr.
this saves a lot of re-integration when the trunk or relase base changes.
so client will see what ever the ordermgr controller serves up once the
client does an action.

If I changes something like say the order statuses then the code I
changed, as well as the screens are in my application.

to return to my menu, they click on the only tab visible, which is my
application tab.

I do have Ecas and services in my app that extends ofbiz, but is unique
to Yahoo functions.

so to upgrade from the release to the trunk, I just move my app into the
trunk copy I made and add the folder to the trunks component-load.xml

to get back to the original problem I need a way to declare the
mainDecoratorLocation that has different paths so it can be read when
the controller for that component is read.
then I will let what ever reads it preappend the component name to
mainDecoratorLocation, and track it.

so time to dig into the code.
:)


Jonathon -- Improov sent the following on 11/22/2007 3:22 AM:

> Your use case seems valid.
>
> In a nutshell, you're simply cloning a webapp, and then extending it
> with your own requests and features.
>
> That's great. It means you won't have to repeat the scores of request
> maps in the webapp you're cloning.
>
> That said, it's pretty scary to see 6 webapps rolled into 1 (your custom
> webapp, where you extend original OFBiz codes). Still, it's just a
> matter of splitting up those 6 webapps into 6 custom webapps, something
> you may do when you have time.
>
> I can see where having the mainDecoratorLocation parameter tied to the
> webapp (controller.xml) can be useful. But I find it hard to vote for
> making this extension to the OFBiz framework. You can simply extend
> webapp "workeffort" with "myworkeffort", and use the same
> mainDecoratorLocation that "workeffort" uses. In short, there's a simple
> and useful workaround now.
>
> Over time, it will be nice to be able to clone "workeffort" and let it
> use its own mainDecoratorLocation, while my extensions in "myworkeffort"
> use a different mainDecoratorLocation. No clash.
>
> I think I've worn myself out trying to explain technical issues in
> technical terms. Let me try an analogy. So, for the last time...
>
> Customer: "I want a hamburger."
>
> Cashier: "What's the code to activate my POS machine?"
>
> Customer: "I don't know?"
>
> Cashier: "Sorry, you need to know, or no hamburger for you."
>
> Customer: "Don't you know?"
>
> Cashier: "I know it for that other POS machine, not this one. You're
> ordering a hamburger from this one, so I can't serve you unless you got
> the code!"
>
> Customer: "I want to talk to your manager."
>
> Cashier: "Alright. He'll probably ask you write some codes to read the
> web.xml file in that other POS machine and retrieve the code
> (mainDecoratorLocation) there, so be prepared."
>
> Jonathon
>
> BJ Freeman wrote:
>> I have some screens I handle differently.
>> I have kept from going crazy by calling the ones and let the controller
>> in that app handle it.
>> I have not had any problems so far, except for mainDecoratorLocation
>>
>> and from what I am reading it should not be where it is to follow best
>> practices.
>>
>> question is where to put it.
>>
>>
>>
>> Chris Howe sent the following on 11/22/2007 12:10 AM:
>>> Why are you opposed to running 6 separate webapps under a component?
>>> mycomponent/webapp
>>>                                    /myworkeffort
>>>                                    /mypartymgr
>>>                                    /mymarketing
>>>                                    /myordermgr
>>>                                    /myaccounting
>>>
>>>                                    /myyahoo
>>>
>>>
>>> I can almost guarantee you'll drive yourself insane with request-maps
>>> and view-maps overriding each other and giving unexpected results.
>>>
>>> ----- Original Message ----
>>> From: BJ Freeman <[hidden email]>
>>> To: [hidden email]
>>> Sent: Thursday, November 22, 2007 1:58:37 AM
>>> Subject: Re: mainDecoratorLocation change to
>>> [applicationname]mainDecoratorLocation
>>>
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> 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 <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>

[jonwimp]

BJ,

Understood. As I had suspected, you wanted a single look, single application, one tab.

 > I am not moving any code from the trunk or ver 4.0 into my app.

Yes, you're doing great extending OFBiz cleanly.

 > If I changes something like say the order statuses then the code I changed,
 > as well as the screens are in my application.

Sounds right. Extension codes are cleanly separated from original OFBiz codes.

 > to get back to the original problem I need a way to declare the
 > mainDecoratorLocation that has different paths so it can be read when the
 > controller for that component is read.

As mentioned, you need to change ConfigXMLReader, possibly ControlServlet and RequestManager. Just
add a new top-level (below <site-conf>) element called "<main-decorator-loc>". The ConfigXMLReader
will prepend the webapp name to "mainDecoratorLocation", so you get something like
"ordermgr:mainDecoratorLocation".

Or easier, simply change those same classes to read the web.xml file instead. Read the web.xml
file in the same folder as the included (<include>) controller.xml .

 > then I will let what ever reads it preappend the component name to
 > mainDecoratorLocation, and track it.

You need to change ModelScreenWidget, and add some additional processing for attribute "location".

Whenever ModelScreenWidget sees in attribute "location" a value of
"${parameters.mainDecoratorLocation}", it will create a FlexibleStringExpander with string
"${parameters.ordermgr:mainDecoratorLocation}" instead.

I too love to cleanly organize code like this, rather than mess up OFBiz's internals. I wish you
success in implementing this, which is easy enough. Hope you can get this into OFBiz SVN so I can
have it too. :)

Jonathon
BJ Freeman wrote:

> Just to clarify, I consider my app an overlay.
> I am not moving any code from the trunk or ver 4.0 into my app.
> for instance I am merging two ftl in Ordermgr.
> I do create a widget but the ftl are till in ordermgr.
> this saves a lot of re-integration when the trunk or relase base changes.
> so client will see what ever the ordermgr controller serves up once the
> client does an action.
>
> If I changes something like say the order statuses then the code I
> changed, as well as the screens are in my application.
>
> to return to my menu, they click on the only tab visible, which is my
> application tab.
>
> I do have Ecas and services in my app that extends ofbiz, but is unique
> to Yahoo functions.
>
> so to upgrade from the release to the trunk, I just move my app into the
> trunk copy I made and add the folder to the trunks component-load.xml
>
> to get back to the original problem I need a way to declare the
> mainDecoratorLocation that has different paths so it can be read when
> the controller for that component is read.
> then I will let what ever reads it preappend the component name to
> mainDecoratorLocation, and track it.
>
> so time to dig into the code.
> :)
>
>
> Jonathon -- Improov sent the following on 11/22/2007 3:22 AM:
>> Your use case seems valid.
>>
>> In a nutshell, you're simply cloning a webapp, and then extending it
>> with your own requests and features.
>>
>> That's great. It means you won't have to repeat the scores of request
>> maps in the webapp you're cloning.
>>
>> That said, it's pretty scary to see 6 webapps rolled into 1 (your custom
>> webapp, where you extend original OFBiz codes). Still, it's just a
>> matter of splitting up those 6 webapps into 6 custom webapps, something
>> you may do when you have time.
>>
>> I can see where having the mainDecoratorLocation parameter tied to the
>> webapp (controller.xml) can be useful. But I find it hard to vote for
>> making this extension to the OFBiz framework. You can simply extend
>> webapp "workeffort" with "myworkeffort", and use the same
>> mainDecoratorLocation that "workeffort" uses. In short, there's a simple
>> and useful workaround now.
>>
>> Over time, it will be nice to be able to clone "workeffort" and let it
>> use its own mainDecoratorLocation, while my extensions in "myworkeffort"
>> use a different mainDecoratorLocation. No clash.
>>
>> I think I've worn myself out trying to explain technical issues in
>> technical terms. Let me try an analogy. So, for the last time...
>>
>> Customer: "I want a hamburger."
>>
>> Cashier: "What's the code to activate my POS machine?"
>>
>> Customer: "I don't know?"
>>
>> Cashier: "Sorry, you need to know, or no hamburger for you."
>>
>> Customer: "Don't you know?"
>>
>> Cashier: "I know it for that other POS machine, not this one. You're
>> ordering a hamburger from this one, so I can't serve you unless you got
>> the code!"
>>
>> Customer: "I want to talk to your manager."
>>
>> Cashier: "Alright. He'll probably ask you write some codes to read the
>> web.xml file in that other POS machine and retrieve the code
>> (mainDecoratorLocation) there, so be prepared."
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> I have some screens I handle differently.
>>> I have kept from going crazy by calling the ones and let the controller
>>> in that app handle it.
>>> I have not had any problems so far, except for mainDecoratorLocation
>>>
>>> and from what I am reading it should not be where it is to follow best
>>> practices.
>>>
>>> question is where to put it.
>>>
>>>
>>>
>>> Chris Howe sent the following on 11/22/2007 12:10 AM:
>>>> Why are you opposed to running 6 separate webapps under a component?
>>>> mycomponent/webapp
>>>>                                    /myworkeffort
>>>>                                    /mypartymgr
>>>>                                    /mymarketing
>>>>                                    /myordermgr
>>>>                                    /myaccounting
>>>>
>>>>                                    /myyahoo
>>>>
>>>>
>>>> I can almost guarantee you'll drive yourself insane with request-maps
>>>> and view-maps overriding each other and giving unexpected results.
>>>>
>>>> ----- Original Message ----
>>>> From: BJ Freeman <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Thursday, November 22, 2007 1:58:37 AM
>>>> Subject: Re: mainDecoratorLocation change to
>>>> [applicationname]mainDecoratorLocation
>>>>
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>>>> To: [hidden email]
>>>>>>>> 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 <[hidden email]>
>>>>>>>>> To: [hidden email]
>>>>>>>>> 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.
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>

[Scott Gray]

How on earth could this work?  Each main-decorator specifies an
appheaderTemplate which displays the navigation menu for that application,
how is the user navigating between the various applications that you have
bundled into one?  Have you replaced/altered the GlobalDecorator to display
the "sub" applications?

I really don't think your following best practices here and that is exactly
why you are having troubles.  If you want to have a single component in
which to maintain your customizations you should follow the ecomclone
example and put a webapp entry for each base app in your ofbiz-component.xml
.

Regards
Scott

On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:

>
> BJ,
>
> Understood. As I had suspected, you wanted a single look, single
> application, one tab.
>
> > I am not moving any code from the trunk or ver 4.0 into my app.
>
> Yes, you're doing great extending OFBiz cleanly.
>
> > If I changes something like say the order statuses then the code I
> changed,
> > as well as the screens are in my application.
>
> Sounds right. Extension codes are cleanly separated from original OFBiz
> codes.
>
> > to get back to the original problem I need a way to declare the
> > mainDecoratorLocation that has different paths so it can be read when
> the
> > controller for that component is read.
>
> As mentioned, you need to change ConfigXMLReader, possibly ControlServlet
> and RequestManager. Just
> add a new top-level (below <site-conf>) element called
> "<main-decorator-loc>". The ConfigXMLReader
> will prepend the webapp name to "mainDecoratorLocation", so you get
> something like
> "ordermgr:mainDecoratorLocation".
>
> Or easier, simply change those same classes to read the web.xml file
> instead. Read the web.xml
> file in the same folder as the included (<include>) controller.xml .
>
> > then I will let what ever reads it preappend the component name to
> > mainDecoratorLocation, and track it.
>
> You need to change ModelScreenWidget, and add some additional processing
> for attribute "location".
>
> Whenever ModelScreenWidget sees in attribute "location" a value of
> "${parameters.mainDecoratorLocation}", it will create a
> FlexibleStringExpander with string
> "${parameters.ordermgr:mainDecoratorLocation}" instead.
>
> I too love to cleanly organize code like this, rather than mess up OFBiz's
> internals. I wish you
> success in implementing this, which is easy enough. Hope you can get this
> into OFBiz SVN so I can
> have it too. :)
>
> Jonathon
> BJ Freeman wrote:
> > Just to clarify, I consider my app an overlay.
> > I am not moving any code from the trunk or ver 4.0 into my app.
> > for instance I am merging two ftl in Ordermgr.
> > I do create a widget but the ftl are till in ordermgr.
> > this saves a lot of re-integration when the trunk or relase base
> changes.
> > so client will see what ever the ordermgr controller serves up once the
> > client does an action.
> >
> > If I changes something like say the order statuses then the code I
> > changed, as well as the screens are in my application.
> >
> > to return to my menu, they click on the only tab visible, which is my
> > application tab.
> >
> > I do have Ecas and services in my app that extends ofbiz, but is unique
> > to Yahoo functions.
> >
> > so to upgrade from the release to the trunk, I just move my app into the
> > trunk copy I made and add the folder to the trunks component-load.xml
> >
> > to get back to the original problem I need a way to declare the
> > mainDecoratorLocation that has different paths so it can be read when
> > the controller for that component is read.
> > then I will let what ever reads it preappend the component name to
> > mainDecoratorLocation, and track it.
> >
> > so time to dig into the code.
> > :)
> >
> >
> > Jonathon -- Improov sent the following on 11/22/2007 3:22 AM:
> >> Your use case seems valid.
> >>
> >> In a nutshell, you're simply cloning a webapp, and then extending it
> >> with your own requests and features.
> >>
> >> That's great. It means you won't have to repeat the scores of request
> >> maps in the webapp you're cloning.
> >>
> >> That said, it's pretty scary to see 6 webapps rolled into 1 (your
> custom
> >> webapp, where you extend original OFBiz codes). Still, it's just a
> >> matter of splitting up those 6 webapps into 6 custom webapps, something
> >> you may do when you have time.
> >>
> >> I can see where having the mainDecoratorLocation parameter tied to the
> >> webapp (controller.xml) can be useful. But I find it hard to vote for
> >> making this extension to the OFBiz framework. You can simply extend
> >> webapp "workeffort" with "myworkeffort", and use the same
> >> mainDecoratorLocation that "workeffort" uses. In short, there's a
> simple
> >> and useful workaround now.
> >>
> >> Over time, it will be nice to be able to clone "workeffort" and let it
> >> use its own mainDecoratorLocation, while my extensions in
> "myworkeffort"
> >> use a different mainDecoratorLocation. No clash.
> >>
> >> I think I've worn myself out trying to explain technical issues in
> >> technical terms. Let me try an analogy. So, for the last time...
> >>
> >> Customer: "I want a hamburger."
> >>
> >> Cashier: "What's the code to activate my POS machine?"
> >>
> >> Customer: "I don't know?"
> >>
> >> Cashier: "Sorry, you need to know, or no hamburger for you."
> >>
> >> Customer: "Don't you know?"
> >>
> >> Cashier: "I know it for that other POS machine, not this one. You're
> >> ordering a hamburger from this one, so I can't serve you unless you got
> >> the code!"
> >>
> >> Customer: "I want to talk to your manager."
> >>
> >> Cashier: "Alright. He'll probably ask you write some codes to read the
> >> web.xml file in that other POS machine and retrieve the code
> >> (mainDecoratorLocation) there, so be prepared."
> >>
> >> Jonathon
> >>
> >> BJ Freeman wrote:
> >>> I have some screens I handle differently.
> >>> I have kept from going crazy by calling the ones and let the
> controller
> >>> in that app handle it.
> >>> I have not had any problems so far, except for mainDecoratorLocation
> >>>
> >>> and from what I am reading it should not be where it is to follow best
> >>> practices.
> >>>
> >>> question is where to put it.
> >>>
> >>>
> >>>
> >>> Chris Howe sent the following on 11/22/2007 12:10 AM:
> >>>> Why are you opposed to running 6 separate webapps under a component?
> >>>> mycomponent/webapp
> >>>>                                    /myworkeffort
> >>>>                                    /mypartymgr
> >>>>                                    /mymarketing
> >>>>                                    /myordermgr
> >>>>                                    /myaccounting
> >>>>
> >>>>                                    /myyahoo
> >>>>
> >>>>
> >>>> I can almost guarantee you'll drive yourself insane with request-maps
> >>>> and view-maps overriding each other and giving unexpected results.
> >>>>
> >>>> ----- Original Message ----
> >>>> From: BJ Freeman <[hidden email]>
> >>>> To: [hidden email]
> >>>> Sent: Thursday, November 22, 2007 1:58:37 AM
> >>>> Subject: Re: mainDecoratorLocation change to
> >>>> [applicationname]mainDecoratorLocation
> >>>>
> >>>> 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 <[hidden email]>
> >>>>> To: [hidden email]
> >>>>> 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 <[hidden email]>
> >>>>>> To: [hidden email]
> >>>>>> 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 <[hidden email]>
> >>>>>>>> To: [hidden email]
> >>>>>>>> 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 <[hidden email]>
> >>>>>>>>> To: [hidden email]
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
>
>