I would agree with the solution you offered of sending the views to custom
application screens that dictate how the controller is to be used.. BJ does
not. BJ doesn't want to create any screens in his custom application.
----- Original Message ----
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 12:20:23 PM
Subject: Re: Include of controllers
I don't agree that that is the only way to solve the problem. I have
suggested the CORRECT solution
to this problem ever since the beginning of this thread, but that
solution is being ignored, and
instead it is being replced with a kludge that tries to fix a SYMPTOM,
and not the real problem.
-Adrian
Chris Howe wrote:
> BJ's problem occurs because when he <include>s the party
> controller and the catalog controller, he wants the requests/views
from
> the party controller to have mainDecoratorLocation equal one place
and
> the requests/views from the catalog controller to equal another.
>
> The only way for it to solve BJ's issue is to replace current
${parameters.mainDecoratorLocation} with
${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation}
or
to remove the variable location altogether, thus breaking the ability
call that screen from a custom application. Not simply provide a variable
to <decororator-screen> location's that are empty.
>
>
>
>
> ----- Original Message ----
> From: Adrian Crum <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 11:46:26 AM
> Subject: Re: Include of controllers
>
>
> If BJ supplies a patch as I described, then we'll see if it solves
his
> problem. If it does, then
> we're talking about the same issue. ;-)
>
> -Adrian
>
> Chris Howe wrote:
>
>
>>You two are talking about different issues. BJ is describing a
>
> pitfall that occurs when you use the <include> tag in the controller
for a
> scenario that wasn't considered when the <include> tag was
implemented
> in the controller.
>
>>----- Original Message ----
>>From: Adrian Crum <[EMAIL PROTECTED]>
>>To: dev@ofbiz.apache.org
>>Sent: Monday, December 17, 2007 11:33:43 AM
>>Subject: Re: Include of controllers
>>
>>
>>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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
>
