mainDecoratorLocation change to [applicationname]mainDecoratorLocation

[jonwimp]

Oh yeah, that's right! Good catch.

BJ, you'll have to change component://common/widget/CommonScreens.xml#GlobalDecorator a bit.

Add a higher-priority overriding variable say "forceAppHeaderTemplate". If that parameter is
present, "appHeaderTemplate" will be ignored. Just FYI, the "appHeaderTemplate" deals with the
horizontal menu at the top of the screen. I imagine you would want your own menu items there.

All these fixes will mean you won't have to change any screen widgets in order to bundle them into
your special giant webapp.

Is there anyone else doing this giant webapp pattern? I've only ever been asked to extend an
original webapp and mount it on a different request path, at most. The problem that BJ encountners
should only come when we combine 2 or more original webapps together.

Let me know how it goes!

Jonathon

Scott Gray wrote:

> 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.
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 11/22/2007 6:55 PM

[Scott Gray]

This whole scenario makes no sense to me and I really can't see any benefits
to be had from pursuing it.

Regards
Scott

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

>
> Oh yeah, that's right! Good catch.
>
> BJ, you'll have to change
> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>
> Add a higher-priority overriding variable say "forceAppHeaderTemplate". If
> that parameter is
> present, "appHeaderTemplate" will be ignored. Just FYI, the
> "appHeaderTemplate" deals with the
> horizontal menu at the top of the screen. I imagine you would want your
> own menu items there.
>
> All these fixes will mean you won't have to change any screen widgets in
> order to bundle them into
> your special giant webapp.
>
> Is there anyone else doing this giant webapp pattern? I've only ever been
> asked to extend an
> original webapp and mount it on a different request path, at most. The
> problem that BJ encountners
> should only come when we combine 2 or more original webapps together.
>
> Let me know how it goes!
>
> Jonathon
>
> Scott Gray wrote:
> > 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.xmlfor
> >>>>>>   <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.
> >>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
> 11/22/2007 6:55 PM
>
>

[jonwimp]

I wouldn't discourage BJ from exploring and implementing this.

All of us have had weird requirements or scenarios that don't quite fit in with OFBiz conventions.
To be honest, the EFT is one sticky example; every client I know here says that's not the way it's
handled by the banks or businesses in their locale.

BJ's scenario seems to make sense to him, even though I can't fully identify with it. I've also
had clients who didn't just look at the GUI, but also looked at the URL. They wanted the URL to
look exactly the way they want. Some want SEO-friendly URLs, some want it real short, some want
only their big company name in there and nothing else, etc.

I say let BJ try this.

Jonathon

Scott Gray wrote:

> This whole scenario makes no sense to me and I really can't see any benefits
> to be had from pursuing it.
>
> Regards
> Scott
>
> On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>> Oh yeah, that's right! Good catch.
>>
>> BJ, you'll have to change
>> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>>
>> Add a higher-priority overriding variable say "forceAppHeaderTemplate". If
>> that parameter is
>> present, "appHeaderTemplate" will be ignored. Just FYI, the
>> "appHeaderTemplate" deals with the
>> horizontal menu at the top of the screen. I imagine you would want your
>> own menu items there.
>>
>> All these fixes will mean you won't have to change any screen widgets in
>> order to bundle them into
>> your special giant webapp.
>>
>> Is there anyone else doing this giant webapp pattern? I've only ever been
>> asked to extend an
>> original webapp and mount it on a different request path, at most. The
>> problem that BJ encountners
>> should only come when we combine 2 or more original webapps together.
>>
>> Let me know how it goes!
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>> 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.xmlfor
>>>>>>>>   <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.
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>> 11/22/2007 6:55 PM
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 11/22/2007 6:55 PM

[Scott Gray]

I'm not saying don't do it, I'm just saying I can't see the benefits.  If it
works for BJ that great, but I'm yet to hear anything that would IMO
justify changing the current mainDecoratorLocation pattern which ultimately
is what this thread is all about (a request to change something in the
trunk).

Regards
Scott

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

>
> I wouldn't discourage BJ from exploring and implementing this.
>
> All of us have had weird requirements or scenarios that don't quite fit in
> with OFBiz conventions.
> To be honest, the EFT is one sticky example; every client I know here says
> that's not the way it's
> handled by the banks or businesses in their locale.
>
> BJ's scenario seems to make sense to him, even though I can't fully
> identify with it. I've also
> had clients who didn't just look at the GUI, but also looked at the URL.
> They wanted the URL to
> look exactly the way they want. Some want SEO-friendly URLs, some want it
> real short, some want
> only their big company name in there and nothing else, etc.
>
> I say let BJ try this.
>
> Jonathon
>
> Scott Gray wrote:
> > This whole scenario makes no sense to me and I really can't see any
> benefits
> > to be had from pursuing it.
> >
> > Regards
> > Scott
> >
> > On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
> >> Oh yeah, that's right! Good catch.
> >>
> >> BJ, you'll have to change
> >> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
> >>
> >> Add a higher-priority overriding variable say "forceAppHeaderTemplate".
> If
> >> that parameter is
> >> present, "appHeaderTemplate" will be ignored. Just FYI, the
> >> "appHeaderTemplate" deals with the
> >> horizontal menu at the top of the screen. I imagine you would want your
> >> own menu items there.
> >>
> >> All these fixes will mean you won't have to change any screen widgets
> in
> >> order to bundle them into
> >> your special giant webapp.
> >>
> >> Is there anyone else doing this giant webapp pattern? I've only ever
> been
> >> asked to extend an
> >> original webapp and mount it on a different request path, at most. The
> >> problem that BJ encountners
> >> should only come when we combine 2 or more original webapps together.
> >>
> >> Let me know how it goes!
> >>
> >> Jonathon
> >>
> >> Scott Gray wrote:
> >>> 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.xmlfor
> >>>>>>>>   <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.xmlcontext-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.
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> No virus found in this incoming message.
> >>> Checked by AVG Free Edition.
> >>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
> >> 11/22/2007 6:55 PM
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
> 11/22/2007 6:55 PM
>
>

[jonwimp]

The change required by BJ won't be small. Will likely be quite a long haul implementing it. I
don't see how it can easily go into the trunk either. There are just too many easier workarounds
at the moment. Maybe KIV his implementation until more users need that same pattern.

Later on, with more manpower, we could be more adventurous and re-look this implementation.

Let's see how BJ's exploration goes.

Jonathon

Scott Gray wrote:

> I'm not saying don't do it, I'm just saying I can't see the benefits.  If it
> works for BJ that great, but I'm yet to hear anything that would IMO
> justify changing the current mainDecoratorLocation pattern which ultimately
> is what this thread is all about (a request to change something in the
> trunk).
>
> Regards
> Scott
>
> On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>> I wouldn't discourage BJ from exploring and implementing this.
>>
>> All of us have had weird requirements or scenarios that don't quite fit in
>> with OFBiz conventions.
>> To be honest, the EFT is one sticky example; every client I know here says
>> that's not the way it's
>> handled by the banks or businesses in their locale.
>>
>> BJ's scenario seems to make sense to him, even though I can't fully
>> identify with it. I've also
>> had clients who didn't just look at the GUI, but also looked at the URL.
>> They wanted the URL to
>> look exactly the way they want. Some want SEO-friendly URLs, some want it
>> real short, some want
>> only their big company name in there and nothing else, etc.
>>
>> I say let BJ try this.
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>> This whole scenario makes no sense to me and I really can't see any
>> benefits
>>> to be had from pursuing it.
>>>
>>> Regards
>>> Scott
>>>
>>> On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>>>> Oh yeah, that's right! Good catch.
>>>>
>>>> BJ, you'll have to change
>>>> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>>>>
>>>> Add a higher-priority overriding variable say "forceAppHeaderTemplate".
>> If
>>>> that parameter is
>>>> present, "appHeaderTemplate" will be ignored. Just FYI, the
>>>> "appHeaderTemplate" deals with the
>>>> horizontal menu at the top of the screen. I imagine you would want your
>>>> own menu items there.
>>>>
>>>> All these fixes will mean you won't have to change any screen widgets
>> in
>>>> order to bundle them into
>>>> your special giant webapp.
>>>>
>>>> Is there anyone else doing this giant webapp pattern? I've only ever
>> been
>>>> asked to extend an
>>>> original webapp and mount it on a different request path, at most. The
>>>> problem that BJ encountners
>>>> should only come when we combine 2 or more original webapps together.
>>>>
>>>> Let me know how it goes!
>>>>
>>>> Jonathon
>>>>
>>>> Scott Gray wrote:
>>>>> 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.xmlfor
>>>>>>>>>>   <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.xmlcontext-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.
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>
>> ------------------------------------------------------------------------
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Free Edition.
>>>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>>>> 11/22/2007 6:55 PM
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>> 11/22/2007 6:55 PM
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 11/22/2007 6:55 PM

[BJ Freeman]

let me refocus this conversation.
this is about using the include in the controller to access other
controllers.
This is a feature of ofbiz is it not?
In using this feature there is a problem when the included controller
accesses a widget in its application.

So either remove the feature or make it work correctly.


Scott Gray sent the following on 11/22/2007 9:48 PM:

> 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.
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>

[BJ Freeman]

I think the focus got lost in my explaining what i am doing.
1) the main-decorator defines a path in that application to where it is.
2) the main-decorator is used in the local apps widgets and that may be
where the problem is. Since from this conversation is sounds like it was
meant to be used for the
component://common/widget/CommonScreens.xml#GlobalDecorator
3)So if I am correct then the main-decorator is not following the best
practices in each app by being used by the apps widgets.
4)the uses in the app sould have a app-main-decorator that the
application widget use.
5)if this was implemented, then the problem goes away becuase I can
include the app-main-decorator in my web.xml.



Scott Gray sent the following on 11/22/2007 10:22 PM:

> This whole scenario makes no sense to me and I really can't see any benefits
> to be had from pursuing it.
>
> Regards
> Scott
>
> On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>> Oh yeah, that's right! Good catch.
>>
>> BJ, you'll have to change
>> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>>
>> Add a higher-priority overriding variable say "forceAppHeaderTemplate". If
>> that parameter is
>> present, "appHeaderTemplate" will be ignored. Just FYI, the
>> "appHeaderTemplate" deals with the
>> horizontal menu at the top of the screen. I imagine you would want your
>> own menu items there.
>>
>> All these fixes will mean you won't have to change any screen widgets in
>> order to bundle them into
>> your special giant webapp.
>>
>> Is there anyone else doing this giant webapp pattern? I've only ever been
>> asked to extend an
>> original webapp and mount it on a different request path, at most. The
>> problem that BJ encountners
>> should only come when we combine 2 or more original webapps together.
>>
>> Let me know how it goes!
>>
>> Jonathon
>>
>> Scott Gray wrote:
>>> 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.xmlfor
>>>>>>>>   <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.
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>> 11/22/2007 6:55 PM
>>
>>
>

[BJ Freeman]

to clarify
app-main-decorator means appname-main-decorator

BJ Freeman sent the following on 11/23/2007 4:07 AM:

> I think the focus got lost in my explaining what i am doing.
> 1) the main-decorator defines a path in that application to where it is.
> 2) the main-decorator is used in the local apps widgets and that may be
> where the problem is. Since from this conversation is sounds like it was
> meant to be used for the
> component://common/widget/CommonScreens.xml#GlobalDecorator
> 3)So if I am correct then the main-decorator is not following the best
> practices in each app by being used by the apps widgets.
> 4)the uses in the app sould have a app-main-decorator that the
> application widget use.
> 5)if this was implemented, then the problem goes away becuase I can
> include the app-main-decorator in my web.xml.
>
>
>
> Scott Gray sent the following on 11/22/2007 10:22 PM:
>> This whole scenario makes no sense to me and I really can't see any benefits
>> to be had from pursuing it.
>>
>> Regards
>> Scott
>>
>> On 23/11/2007, Jonathon -- Improov <[hidden email]> wrote:
>>> Oh yeah, that's right! Good catch.
>>>
>>> BJ, you'll have to change
>>> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>>>
>>> Add a higher-priority overriding variable say "forceAppHeaderTemplate". If
>>> that parameter is
>>> present, "appHeaderTemplate" will be ignored. Just FYI, the
>>> "appHeaderTemplate" deals with the
>>> horizontal menu at the top of the screen. I imagine you would want your
>>> own menu items there.
>>>
>>> All these fixes will mean you won't have to change any screen widgets in
>>> order to bundle them into
>>> your special giant webapp.
>>>
>>> Is there anyone else doing this giant webapp pattern? I've only ever been
>>> asked to extend an
>>> original webapp and mount it on a different request path, at most. The
>>> problem that BJ encountners
>>> should only come when we combine 2 or more original webapps together.
>>>
>>> Let me know how it goes!
>>>
>>> Jonathon
>>>
>>> Scott Gray wrote:
>>>> 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.xmlfor
>>>>>>>>>   <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.
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>>> 11/22/2007 6:55 PM
>>>
>>>
>
>
>

[jonwimp]

BJ,

I think many things in life are "work-in-progress", even released versions of software. (Yeah, I
know, I'll be fired if I'm in product marketing.)

That said, I humbly and apologetically put to you (and to myself) that the <include> directive in
controller.xml is not designed for blindly including another webapp's request/view dictionary
(controller.xml) and have it all work like Object-oriented Java programming. See my analogy with
ordering a hamburger from a different POS machine in the same restaurant. No, the <include>
directive can't fix that.

So what is the <include> directive for? What can it do now?

To organize a large controller.xml into smaller ones. We could have a main controller.xml that
includes requests.xml and views.xml, and maybe even handlers.xml . (Can this be done? Verify?) Or
organize by function, rather than by directives (ie, not by <request-map>, <view-map>, etc).

To clone an original webapp, and to call on its requests and views with a mainDecoratorLocation
that works with its screen widgets. The mainDecoratorLocation can point to a decorator that is
either original or modified-but-compatible.

To extend that original webapp with more requests, or with more views and screen widgets that can
also use the same decorator mentioned above.

What is it not used for?

Combining multiple webapps that may need different mainDecoratorLocation values.

In short, I'm sorry to say that the <include> directive is not an "object-oriented" mechanism used
to call on an entire webapp encapsulated in a clean abstraction (using its own
mainDecoratorLocation without us having to know what that is).

But I fully support your ambition to expand the <include> directive's capabilities, as I had amply
indicated in this thread. I had even highlighted the areas that need work to fulfill your
ambition. I do hope you will continue your exploration. I await your findings eagerly, and may
even jump in at points where I feel I can help out. :)

Jonathon

BJ Freeman wrote:

> let me refocus this conversation.
> this is about using the include in the controller to access other
> controllers.
> This is a feature of ofbiz is it not?
> In using this feature there is a problem when the included controller
> accesses a widget in its application.
>
> So either remove the feature or make it work correctly.
>
>
> Scott Gray sent the following on 11/22/2007 9:48 PM:
>> 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.
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>
>

[BJ Freeman]

Ok so the include for controller was only meant for the local app.
that said.
I will implement the easiest way for me, which is to modify each app so
I  can define appname-main-decorator in my web.xml, as I originally
proposed.
however I will not burden the trunk with this concept.
save the heavy stuff for when I have more time.
Got a lot on my plate now.


Jonathon -- Improov sent the following on 11/23/2007 4:28 AM:

> BJ,
>
> I think many things in life are "work-in-progress", even released
> versions of software. (Yeah, I know, I'll be fired if I'm in product
> marketing.)
>
> That said, I humbly and apologetically put to you (and to myself) that
> the <include> directive in controller.xml is not designed for blindly
> including another webapp's request/view dictionary (controller.xml) and
> have it all work like Object-oriented Java programming. See my analogy
> with ordering a hamburger from a different POS machine in the same
> restaurant. No, the <include> directive can't fix that.
>
> So what is the <include> directive for? What can it do now?
>
> To organize a large controller.xml into smaller ones. We could have a
> main controller.xml that includes requests.xml and views.xml, and maybe
> even handlers.xml . (Can this be done? Verify?) Or organize by function,
> rather than by directives (ie, not by <request-map>, <view-map>, etc).
>
> To clone an original webapp, and to call on its requests and views with
> a mainDecoratorLocation that works with its screen widgets. The
> mainDecoratorLocation can point to a decorator that is either original
> or modified-but-compatible.
>
> To extend that original webapp with more requests, or with more views
> and screen widgets that can also use the same decorator mentioned above.
>
> What is it not used for?
>
> Combining multiple webapps that may need different mainDecoratorLocation
> values.
>
> In short, I'm sorry to say that the <include> directive is not an
> "object-oriented" mechanism used to call on an entire webapp
> encapsulated in a clean abstraction (using its own mainDecoratorLocation
> without us having to know what that is).
>
> But I fully support your ambition to expand the <include> directive's
> capabilities, as I had amply indicated in this thread. I had even
> highlighted the areas that need work to fulfill your ambition. I do hope
> you will continue your exploration. I await your findings eagerly, and
> may even jump in at points where I feel I can help out. :)
>
> Jonathon
>
> BJ Freeman wrote:
>> let me refocus this conversation.
>> this is about using the include in the controller to access other
>> controllers.
>> This is a feature of ofbiz is it not?
>> In using this feature there is a problem when the included controller
>> accesses a widget in its application.
>>
>> So either remove the feature or make it work correctly.
>>
>>
>> Scott Gray sent the following on 11/22/2007 9:48 PM:
>>> 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.
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>
>>
>
>
>
>