and just to make this a point
there can be only one
<set field="activeApp" value="catalogmgr" global="true"/>
so if I had my own main-decorator it would not work for calling all
other apps.
BJ Freeman sent the following on 12/17/2007 1:38 PM:
> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>
>>>>
>
>
>
>
