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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
