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