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