Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation

Jonathon -- Improov Thu, 22 Nov 2007 18:25:50 -0800

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. Justadd a new top-level (below <site-conf>) element called "<main-decorator-loc>". The ConfigXMLReaderwill 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.xmlfile 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 yousuccess in implementing this, which is easy enough. Hope you can get this into OFBiz SVN so I canhave 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.

Re: mainDecoratorLocation change to [applicationname]mainDecoratorLocation

Reply via email to