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