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