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



Reply via email to