the other option is not to use the context
location="${parameters.mainDecoratorLocation}"
and put it in the file like
location="component://product/widget/catalog/CatalogCommonScreens.xml"
in the screens this way don't have the problem at all.
Jonathon -- Improov sent the following on 12/15/2007 4:26 PM:
> The common-controller.xml should not use "main-decorator", or that would
> force every webapp in OFBiz (if they include this file) to use a
> "main-decorator" compatible with webcommon screens.
>
> You brought up a good point. I'm now wondering if we should just get
> component://common/widget/CommonScreens.xml#requirePasswordChange to use
> GlobalDecorator instead of main-decorator.
>
> Jonathon
>
> BJ Freeman wrote:
>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
