short answer is I can
but that still would not solve the problem.
take the party main-decorator
<set field="layoutSettings.javaScripts[]"
value="/partymgr/static/partymgr.js" global="true"/>
<set field="layoutSettings.styleSheets[]"
value="/partymgr/static/partymgr.css" global="true"/>
<set field="activeApp" value="partymgr" global="true"/>
<set field="appheaderTemplate"
value="component://party/webapp/partymgr/includes/appheader.ftl"
global="true"/>
not these can not be the same ones if I am calling the product
main-decorator
<set field="activeApp" value="catalogmgr" global="true"/>
<set field="appheaderTemplate"
value="component://product/webapp/catalog/includes/appheader.ftl"
global="true"/>
Scott Gray sent the following on 12/17/2007 1:27 PM:
> Why couldn't you supply your own custom mainDecorator? What do the base
> mainDecorators provide that you can't in your custom app?
>
> Scott
>
> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>> 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.xmlincluded
>>>>>>>>>> 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.xmlof
>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
