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