did you use two different apps from your app?
yes it will work for one app.
Adrian Crum sent the following on 12/17/2007 1:49 PM:
> The best way to prove it is to code it according to my suggestion and
> test it against the original problem you stated in this thread. It
> works. How do I know that? Because I did it a month ago.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> best way to prove this is to have a menu in a new app.
>> point it to two different screens one in each app.
>> try to get both screens to work with out error.
>> even using your code.
>>
>> BJ Freeman sent the following on 12/17/2007 1:39 PM:
>>
>>> you did not say to change
>>> <decorator-screen name="main-decorator"
>>> location="${parameters.mainDecoratorLocation}">
>>>
>>> so even your change will not work.
>>>
>>> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>>>
>>>> That line wouldn't exist if you made the change I suggested.
>>>>
>>>> Make the code changes, THEN tell me what's wrong with it. Telling me
>>>> what's already wrong with it is pointless - I already know the existing
>>>> code doesn't work.
>>>>
>>>>
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>> I beg to differ with you.
>>>>> where is
>>>>> <decorator-screen
>>>>> name="CommonCommunicationEventDecorator"
>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>
>>>>> defined
>>>>> where is
>>>>> <decorator-screen name="main-decorator"
>>>>> location="${parameters.mainDecoratorLocation}">
>>>>> in the CommonPartyDecorator defined.
>>>>>
>>>>> Adrian Crum sent the following on 12/17/2007 1:03 PM:
>>>>>
>>>>>
>>>>>> ListPartyCommEvents request maps to ListPartyCommEvents view, that
>>>>>> maps
>>>>>> to
>>>>>> component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
>>>>>> contain anything specific to the Party Manager's web.xml file. I
>>>>>> don't
>>>>>> see what the problem is.
>>>>>>
>>>>>> Maybe you should include an exact error message.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
