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.
