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