Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
<decorator-screen name="CommonCommunicationEventDecorator"
location="${parameters.mainDecoratorLocation}">
which is the CommonSreens.xml
which has
<decorator-screen name="main-decorator"
location="${parameters.mainDecoratorLocation}">
the main-decorator has
<include-screen name="GlobalDecorator"
location="component://common/widget/CommonScreens.xml"/>
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when screens
> are nested as follows:
>
> <screen name="GlobalDecorator">
> <screen name="main-decorator">
> <screen name="sub-decorator">
> <screen name="actual-content">
> ...
> </screen>
> </screen>
> </screen>
> </screen>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> the actual-content screen, errors are generated because
> <decorator-screen name="sub-decorator"
> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
> app's main decorator xml file, and the sub-decorator screen doesn't
> exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
> either have no location specified or use a different parameter for the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the Agreement screens share a common
> sub-decorator (CommonAgreementDecorator) - and that decorator's location
> is specified as ${parameters.agreementDecoratorLocation}. The
> agreementDecoratorLocation parameter isn't defined anywhere, so the
> location= expression evaluates to an empty String - which causes the
> screen widget view handler to look for CommonAgreementDecorator in the
> existing file.
>
> A custom app that reuses one of the Agreement screens will only need to
> specify the mainDecoratorLocation parameter. Since no
> agreementDecoratorLocation parameter is defined in the custom app, the
> sub-decorator in AgreementScreens.xml is used (same as above). If a
> custom app wanted to have a custom sub-decorator, then it can specify
> that decorator's location in the agreementDecoratorLocation parameter.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> I agree, it is not a controller or web.xml issue. However it is when it
>> shows up.
>> I will change them as I come along also.
>> thanks, that is all I wanted to know.
>> do you want to create a jira so I can submit changes?
>>
>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>
>>> As I mentioned before, the problem is with the coding style on some
>>> screens, not with the controller or web.xml files. I recently changed
>>> some of the accounting screens to correct this error.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
>>>> I am not really, trying to attach the context as a whole.
>>>> only trying to get the mainDecoratorLocation
>>>> which is stored as a context in web.xml.
>>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>>> then all applications I call thru my controller, or the included ones,
>>>> will use my mainDecoratorLocation full path.
>>>> Maybe the solution is to put the main-decorator for all apps in the
>>>> framework/commons
>>>> then like in many of the application they have specific decorators that
>>>> include the main-decorator.
>>>> the problems is how to fill in the actions, etcetera
>>>>
>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>
>>>>
>>>>> All the <include> does is grab some xml elements from the location
>>>>> described. Theoretically, It doesn't even need to be from the same
>>>>> server, much less the same app (may have interesting possibilities
>>>>> BTW). This is why I'm having such a hard time understanding why you
>>>>> are trying to attach context to it.
>>>>>
>>>>> ----- Original Message ----
>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>> To: dev@ofbiz.apache.org
>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>> Subject: Re: Include of controllers
>>>>>
>>>>>
>>>>> I was going thru the trunk and noticed this in all the controllers
>>>>> <include
>>>>> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>>>
>>>>>
>>>>> so there is a rule that says you can include a controller not in the
>>>>> same app.
>>>>>
>>>>>
>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>
>>>>>
>>>>>> Almost.
>>>>>> when the included controller view calles a screen in the partymgr
>>>>>
>>>>> screen
>>>>>
>>>>>
>>>>>> , and that screen calls for a parm that is web.xml. the parm is not
>>>>>> availible for the screen and so fails.
>>>>>>
>>>>>> At this time, the way I handle this is to put the parm in my Web.xml.
>>>>>>
>>>>>> My suggestions was that if a call is made to a parm that would be in
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>> applications, in this case partymgr, web.xml, that widget looks up
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>> web.xml for that application to get it.
>>>>>>
>>>>>>
>>>>>> Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>
>>>>>>
>>>>>>> Okay, I've read through the thread. In that case, I might suggest
>>>>>
>>>>> to take a step back and look at what the two functionalities were
>>>>> designed to accomplish.
>>>>>>> Creating the mainDecoratorLocation variable in the web.xml was
>>>>>
>>>>> designed for _screen reuse. the include element in the controller.xml
>>>>> file
>>>>> was designed for request/response maintenance.
>>>>>>> With that in mind, you can include another controller in your custom
>>>>>
>>>>> application and then override the view with one that points to your
>>>>> application. If you wish to then include a screen from another
>>>>> application you can use the <include-screen> element in the screen
>>>>> widget and
>>>>> at the same time pass a parameters.mainDecoratorLocation to
>>>>> override the
>>>>> one gained from the web.xml context of the webapp being used.
>>>>>
>>>>>
>>>>>>> It appears that what BJ is suggesting would make the screen being
>>>>>
>>>>> called from the ofbiz application nonreusable except as decorated
>>>>> as it
>>>>> is in the ofbiz project which defeats the entire purpose of the
>>>>> mainDecoratorLocation variable. Do I follow correctly?
>>>>>
>>>>>
>>>>>>> ----- Original Message ----
>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>> To: dev@ofbiz.apache.org
>>>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>> Subject: Re: Include of controllers
>>>>>>>
>>>>>>> Chris the discussion is about using the include in the controller.
>>>>>>> and that the current way of putting the locations of parameters used
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>>>> the widgets for screen decorators is causing a problem
>>>>>>> In a lot of apps the location is called out in the web.xml
>>>>>>> <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 suggeston is to take the location out to the web.xml and put in
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>> widget like so.
>>>>>>>
>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>
>>>>>>>
>>>>>>>> I haven't been following the thread, but instead of setting it
>>>>>>>
>>>>>>> explicitly in the widgets section, you may prefer to define it in
>>>>>
>>>>> the actions
>>>>>
>>>>>
>>>>>>> section...
>>>>>>>
>>>>>>>
>>>>>>>> <action>
>>>>>>>> <set field="parameters.mainDecoratorLocation"
>>>>>>>
>>>>>>> value="component://party/widget/partymgr/CommonScreens.xml"/>
>>>>>>>
>>>>>>>> </action>
>>>>>>>> <widget>
>>>>>>>> <include-screen name="splitScreen"/>
>>>>>>>> </widget>
>>>>>>>> ...
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>
>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>
>>>>>>>> <screen name="splitScreen">
>>>>>>>> ...
>>>>>>>> <widget>
>>>>>>>>
>>>>>>>> </widget>
>>>>>>>> ...
>>>>>>>> or something similar that it remains a variable so that you can
>>>>>
>>>>> later
>>>>>
>>>>>
>>>>>>> split the widget section out to be it's own screen so that it can
>>>>>
>>>>> be
>>>>>
>>>>>
>>>>>>> used with the decorator in another webapp. I don't know if the
>>>>>
>>>>> screens
>>>>>
>>>>>
>>>>>>> you're worried about here are that complex. This has been a
>>>>>
>>>>> better
>>>>>
>>>>>
>>>>>>> pattern for me.
>>>>>>>
>>>>>>>
>>>>>>>> ----- Original Message ----
>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>
>>>>>>>> Just want to make sure we are all on the same page
>>>>>>>> in a widget screen
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>>
>>>>>>>> parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>
>>>>>>>> <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>
>>>>>>>>
>>>>>>>> so to "fix"
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>>
>>>>>>>>
>>>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Ok so the code that allows the context to be used in the web.xml
>>>>>
>>>>> is
>>>>>
>>>>>
>>>>>>>>> being depreciated?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> BJ,
>>>>>>>>>>
>>>>>>>>>> Nothing is being reversed. You have pointed out a weakness in how
>>>>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>>> some of the party manager screens are set up (they can't be
>>>>>>>
>>>>>>> reused).
>>>>>>>
>>>>>>>
>>>>>>>> I
>>>>>>>>
>>>>>>>>
>>>>>>>>>> have confirmed they have a problem. So submitting a patch FIXES
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>>>>> issue - it doesn't reverse anything.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I will not submit a patch for what I am proposing, like a lot of
>>>>>>>
>>>>>>> my
>>>>>>>
>>>>>>>
>>>>>>>>>>> code, it stays in the applications I am doing.
>>>>>>>>>>> and since someone else put effort into what is in ofbiz now
>>>>>>>>>>> I do not plan to put effort into reversing it.
>>>>>>>>>>> :)
>>>>>>>>>>>
>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> BJ,
>>>>>>>>>>>>
>>>>>>>>>>>> As I mentioned before, I believe it would be better/easier to
>>>>>
>>>>> fix
>>>>>
>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> party manager screens. Including web.xml files will open up a
>>>>>
>>>>> big
>>>>>
>>>>>
>>>>>>>> can of
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> worms.
>>>>>>>>>>>>
>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>
>>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hans:
>>>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator location
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> context in web.xml
>>>>>>>>>>>>> this was done by someone else and is a standard through ofbiz
>>>>>
>>>>> as
>>>>>
>>>>>
>>>>>>>> far as
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> i can tell.
>>>>>>>>>>>>> I take the path of least resistance.
>>>>>>>>>>>>> Since it is possible to put context in the web.xml and someone
>>>>>>>>
>>>>>>>> has
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> put a
>>>>>>>>>>>>> lot of effort into refactoring ofbiz to this standard, I have
>>>>>
>>>>> no
>>>>>
>>>>>
>>>>>>>>>>>>> intention of undoing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> so my focus for my code will be to have the web.xml included
>>>>>
>>>>> as
>>>>>
>>>>>
>>>>>>>> well,
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> unless the powers to be say there is going to be a change in
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>>> best
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Bj,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> request (or provide a patch) that the
>>>>>>>>>>>>>> CommonCommunicationEventDecorator
>>>>>>>>>>>>>> is moved to the xml file as defined in the web.xml parameter.
>>>>>>>>
>>>>>>>> Also
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> request that the 'location' parameter is defined in the
>>>>>
>>>>> screen
>>>>>
>>>>>
>>>>>>>> you are
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> using.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then you can use this screen in your own application using
>>>>>
>>>>> your
>>>>>
>>>>>
>>>>>>>> own
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>> decorator.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a controller.xml
>>>>>>>>>>>>>>> it has the include for the partymgr in it.
>>>>>>>>>>>>>>> I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>> I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>> so I get to the find screen OK.
>>>>>>>>>>>>>>> I have a few others in my web.xml as well.
>>>>>>>>>>>>>>> so I can navigate.
>>>>>>>>>>>>>>> however if you don't have these in your web.xml that is in
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>>> same
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> directory as the controller.xml you are using
>>>>>>>>>>>>>>> https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>> then you get messages like this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> org.ofbiz.base.util.GeneralException: Error rendering screen
>>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find screen
>>>>>
>>>>> with
>>>>>
>>>>>
>>>>>>>> name
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as the
>>>>>>>>
>>>>>>>> screen
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find screen with
>>>>>
>>>>> name
>>>>>
>>>>>
>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as the
>>>>>>>>
>>>>>>>> screen
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> name [EditCommunicationEvent])
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you have any specific examples of what you're describing?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:59 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> sorry not a complete thougt
>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>> and there is a commonscreen.xml defined in the web.xml of
>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>> controller application it causes an error.
>>>>>>>>>>>>>>>> so maybe puttting the application name before
>>>>>
>>>>> commonescreens
>>>>>
>>>>>
>>>>>>>> will
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>> eliminate that.
>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>>> and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> another is that when the the other widget from the
>>>>>
>>>>> included
>>>>>
>>>>>
>>>>>>>>>>>>>>>>> controller
>>>>>>>>>>>>>>>>> calls for a context that is in the web.xml of that
>>>>>>>>
>>>>>>>> application.
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>> it is not found.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
