You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by BJ Freeman <bj...@free-man.net> on 2007/12/17 22:53:31 UTC
Re: mainDecoratorLocation change to app-mainDecoratorLocation was
Include of controllers
Ok so if we just change mainDecoratorLocation to
party-mainDecoratorLocation
everything will work
I can just include in my web.xml
one for each app I am using.
they will thier own main-decorators and everthing works as it should.
very simple fix.
BJ Freeman sent the following on 12/17/2007 1:44 PM:
> 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 <bj...@free-man.net> 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 <bj...@free-man.net>
>>>>>>>>>>>> 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 <bj...@free-man.net>
>>>>>>>>>>>>>> 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 <bj...@free-man.net>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>
>>
>>
>>
>
>
>
>