Ok I will try to get my head around you solution.
:)
Adrian Crum sent the following on 12/17/2007 10:42 AM:
> Actually, it would be better if we stuck to the original example you
> gave - communication events in the Party Manager component. Have you
> tried the solution I offerred?
>
> -Adrian
>
> Adrian Crum wrote:
>
>> Exactly. That's because the screen was designed poorly. If the
>> products screen was fixed as I suggested, then it would work as you
>> would expect.
>>
>> BJ Freeman wrote:
>>
>>> The problem is any screen that used
>>> location="${parameters.mainDecoratorLocation}
>>> will can not be called from a remote controller that includes the
>>> controller for that app.
>>> so if myapp controller includes the products controller and that then
>>> brings up a view in products. it will not find the
>>> parameters.mainDecoratorLocation for products
>>> and will error.
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
>>>> BJ,
>>>>
>>>> Go ahead and create one. I will work on it when I have time.
>>>>
>>>> To be sure we're all on the same page, the problem exists when screens
>>>> are nested as follows:
>>>>
>>>> <screen name="GlobalDecorator">
>>>> <screen name="main-decorator">
>>>> <screen name="sub-decorator">
>>>> <screen name="actual-content">
>>>> ...
>>>> </screen>
>>>> </screen>
>>>> </screen>
>>>> </screen>
>>>>
>>>> and the location of the sub-decorator screen is defined as
>>>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>>>> the actual-content screen, errors are generated because
>>>> <decorator-screen name="sub-decorator"
>>>> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
>>>> app's main decorator xml file, and the sub-decorator screen doesn't
>>>> exist there.
>>>>
>>>> The solution to the problem is to avoid using
>>>> ${parameters.mainDecoratorLocation} as a location for sub-decorators
>>>> and
>>>> either have no location specified or use a different parameter for the
>>>> sub-decorator's location - like ${subDecoratorLocation}.
>>>>
>>>> A good example of this approach is in AgreementScreens.xml in the
>>>> Accounting component. All of the Agreement screens share a common
>>>> sub-decorator (CommonAgreementDecorator) - and that decorator's
>>>> location
>>>> is specified as ${parameters.agreementDecoratorLocation}. The
>>>> agreementDecoratorLocation parameter isn't defined anywhere, so the
>>>> location= expression evaluates to an empty String - which causes the
>>>> screen widget view handler to look for CommonAgreementDecorator in the
>>>> existing file.
>>>>
>>>> A custom app that reuses one of the Agreement screens will only need to
>>>> specify the mainDecoratorLocation parameter. Since no
>>>> agreementDecoratorLocation parameter is defined in the custom app, the
>>>> sub-decorator in AgreementScreens.xml is used (same as above). If a
>>>> custom app wanted to have a custom sub-decorator, then it can specify
>>>> that decorator's location in the agreementDecoratorLocation parameter.
>>>>
>>>> -Adrian
>>>>
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>> I agree, it is not a controller or web.xml issue. However it is
>>>>> when it
>>>>> shows up.
>>>>> I will change them as I come along also.
>>>>> thanks, that is all I wanted to know.
>>>>> do you want to create a jira so I can submit changes?
>>>>>
>>>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>>>
>>>>>
>>>>>> As I mentioned before, the problem is with the coding style on some
>>>>>> screens, not with the controller or web.xml files. I recently changed
>>>>>> some of the accounting screens to correct this error.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I am not really, trying to attach the context as a whole.
>>>>>>> only trying to get the mainDecoratorLocation
>>>>>>> which is stored as a context in web.xml.
>>>>>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>>>>>> then all applications I call thru my controller, or the included
>>>>>>> ones,
>>>>>>> will use my mainDecoratorLocation full path.
>>>>>>> Maybe the solution is to put the main-decorator for all apps in the
>>>>>>> framework/commons
>>>>>>> then like in many of the application they have specific
>>>>>>> decorators that
>>>>>>> include the main-decorator.
>>>>>>> the problems is how to fill in the actions, etcetera
>>>>>>>
>>>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> All the <include> does is grab some xml elements from the location
>>>>>>>> described. Theoretically, It doesn't even need to be from the same
>>>>>>>> server, much less the same app (may have interesting possibilities
>>>>>>>> BTW). This is why I'm having such a hard time understanding why
>>>>>>>> you
>>>>>>>> are trying to attach context to it.
>>>>>>>>
>>>>>>>> ----- Original Message ----
>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>
>>>>>>>>
>>>>>>>> I was going thru the trunk and noticed this in all the controllers
>>>>>>>> <include
>>>>>>>> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> so there is a rule that says you can include a controller not in
>>>>>>>> the
>>>>>>>> same app.
>>>>>>>>
>>>>>>>>
>>>>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
