Based on this, I can never see how even if I called from a custom app
different screens in different apps how one main-decorator
so I am not sure how this feature would work at all.
Hence my original suggestion that is apps main-decorator be declared as
application-mainDecoratorLocation
this way I could include each apps mainDecoratorLocation and not have to
worry
BJ Freeman sent the following on 12/17/2007 12:55 PM:
> I have a menu, no screens, that calls ListPartyCommEvents
> this goes to the party controller to resolve.
> the party controller uses it view for ListPartyCommEvents
> It can not read the party web.xml so will error even with your changes.
>
> so lets say i put in a mainDecoratorLocation in my web xml and define it
> like the one in the party commonscreens.xml
>
> so far so good.
>
> Now I call a screen in say Product. except the mainDecoratorLocation for
> it has a different main-decorator. so all the requirements are not
> defined in the party main-Decorator I have ported over.
>
> we still have a problem since all the apps main-decorators are not the same.
>
> now if the main-decorators were all the same then I could use one
> location in any of the apps and everything would be ok
>
>
>
> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>> 1. Move the CommonCommunicationEventDecorator screen to the
>> communicationsscreens.xml file.
>> 2. Change all
>> <decorator-screen name="CommonCommunicationEventDecorator"
>> location="${parameters.mainDecoratorLocation}">
>>
>> to
>>
>> <decorator-screen name="CommonCommunicationEventDecorator"
>> location="${parameters.communicationEventDecoratorLocation}">
>>
>> Since parameters.communicationEventDecoratorLocation isn't defined
>> anywhere, the location will evaluate to the current file:
>> communicationsscreens.xml. All communication screens still work the same
>> in Party Manager, but now you can reuse those screens in another app.
>>
>> When you use one of the communication screens in your custom app (via
>> included controller.xml file or otherwise) the
>> parameters.communicationEventDecoratorLocation still isn't defined
>> anywhere, so it still evaluates to the current file:
>> communicationsscreens.xml. The communication screen and the
>> CommonCommunicationEventDecorator will both appear - decorated with your
>> custom app's main decorator.
>>
>> (Optional) If someone didn't like the CommonCommunicationEventDecorator,
>> then they could design their own and specify its location in
>> parameters.communicationEventDecoratorLocation.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>> Ok here is a real situation:
>>> take the party/widgets/partymgr/commicationsscreens.xml
>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>> location="${parameters.mainDecoratorLocation}">
>>> which is the CommonSreens.xml
>>> which has
>>> <decorator-screen name="main-decorator"
>>> location="${parameters.mainDecoratorLocation}">
>>>
>>> the main-decorator has
>>> <include-screen name="GlobalDecorator"
>>> location="component://common/widget/CommonScreens.xml"/>
>>>
>>>
>>> how would the be with your example
>>>
>>>
>>>
>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>
