ah. missed that part.
I think i will put my energy into getting the web.xml included
:)
Adrian Crum sent the following on 11/8/2007 7:58 AM:
> I was suggesting that YOU create the patch - I don't have time to work
> on this right now.
>
> -Adrian
>
> BJ Freeman wrote:
>> yes include the web.xml also
>>
>>
>> before you create a patch make sure it is best practices and it will be
>> folllowed
>> after all they were that way then the context directive started being
>> used.
>> if no one is going to follow this practice you will be patching till you
>> know what freezes over.
>>
>> so right now you have all the application and those in the frame work to
>> patch.
>>
>>
>>
>> Adrian Crum sent the following on 11/7/2007 3:10 PM:
>>
>>> Are you saying this:
>>>
>>> if you include an external controller.xml file in your app's
>>> controller.xml file, then there should be a way to include the external
>>> web.xml in your app's web.xml file too?
>>>
>>> In this particular scenario, I think there is a better way to solve the
>>> problem:
>>>
>>> In the party manager component, move the
>>> CommonCommunicationEventDecorator screen definition into the
>>> CommunicationScreens.xml file, then change the lines that say
>>>
>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>> location="${parameters.mainDecoratorLocation}">
>>>
>>> to
>>>
>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>> location="${parameters.communicationDecoratorLocation}">
>>>
>>> That way you can reuse the communication screens as-is and they will
>>> default to the OOTB decorator screen, OR you can use your own decorator
>>> screen by defining the location of communicationDecoratorLocation in
>>> your app's web.xml file (just like mainDecoratorLocation).
>>>
>>> If that solves your problem, then create a patch and I will
>>> review/commit it.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
>>>> you missed something
>>>> I can simply copy paste the Context into my web.xml since these are
>>>> defined in each apps web.xml.
>>>>
>>>> I am pointing out that what ever is reading the controller in a
>>>> application should also read the web.xml contexts.
>>>> This would make it so there is no need to copy anything.
>>>>
>>>> Adrian Crum sent the following on 11/7/2007 2:19 PM:
>>>>
>>>>
>>>>> It all depends on what you're trying to accomplish and how to
>>>>> tackle it.
>>>>>
>>>>> It appears from your emails that you're including the party manager
>>>>> controller.xml file in a custom app. That is an easy way to gain
>>>>> access
>>>>> to party manager screens within the custom app. But you'll run into
>>>>> problems doing it that way.
>>>>>
>>>>> Another way to approach it is to set up the requests and view maps in
>>>>> your custom app's controller.xml file that point to the screen
>>>>> definitions in the party manager component. From my perspective, that
>>>>> will give you more control.
>>>>>
>>>>> Either way, you'll have a problem with these "sub-decorator" screens.
>>>>> How you handle that issue depends on what your trying to achieve.
>>>>> If you
>>>>> want to use the same decorator screens, then you'll have to C&P them
>>>>> into your custom app's CommonScreens.xml file. If you don't want to
>>>>> use
>>>>> them, then just create empty decorator screens in your custom app's
>>>>> CommonScreens.xml file.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> BJ Freeman wrote:
>>>>>
>>>>>
>>>>>
>>>>>> or if the web.xml context is allowed the lookup should include the
>>>>>> web.xml for that component.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Adrian Crum sent the following on 11/7/2007 1:57 PM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I understand now, thank you for the clarification.
>>>>>>>
>>>>>>> You would have to create your own CommonCommunicationEventDecorator
>>>>>>> decorator in your component's CommonScreens.xml file.
>>>>>>>
>>>>>>> At first glance, it appears the CommunicationScreens.xml file should
>>>>>>> contain the CommonCommunicationEventDecorator screen. That would
>>>>>>> make
>>>>>>> the screens easier to reuse.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
>
>
