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 21:23:41 UTC
Re:mainDecoratorLocation was Include of controllers
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.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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
In that case, activeApp becomes your custom app, and appheaderTemplate points to your custom app
header template. The party manager javascript and stylesheet elements would have to be copied over
to your main-decorator.
BJ Freeman wrote:
> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>
>>>>
>
>
Re: mainDecoratorLocation change to app-mainDecoratorLocation was
Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>
>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>
>>>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Scott Gray <le...@gmail.com>.
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.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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.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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
No, that's not what I said.
BJ Freeman wrote:
> you did not say to change
> <decorator-screen name="main-decorator"
> location="${parameters.mainDecoratorLocation}">
>
> so even your change will not work.
>
> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>
>>That line wouldn't exist if you made the change I suggested.
>>
>>Make the code changes, THEN tell me what's wrong with it. Telling me
>>what's already wrong with it is pointless - I already know the existing
>>code doesn't work.
>>
>>
>>BJ Freeman wrote:
>>
>>
>>>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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
did you use two different apps from your app?
yes it will work for one app.
Adrian Crum sent the following on 12/17/2007 1:49 PM:
> The best way to prove it is to code it according to my suggestion and
> test it against the original problem you stated in this thread. It
> works. How do I know that? Because I did it a month ago.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> best way to prove this is to have a menu in a new app.
>> point it to two different screens one in each app.
>> try to get both screens to work with out error.
>> even using your code.
>>
>> BJ Freeman sent the following on 12/17/2007 1:39 PM:
>>
>>> you did not say to change
>>> <decorator-screen name="main-decorator"
>>> location="${parameters.mainDecoratorLocation}">
>>>
>>> so even your change will not work.
>>>
>>> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>>>
>>>> That line wouldn't exist if you made the change I suggested.
>>>>
>>>> Make the code changes, THEN tell me what's wrong with it. Telling me
>>>> what's already wrong with it is pointless - I already know the existing
>>>> code doesn't work.
>>>>
>>>>
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>> 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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
The best way to prove it is to code it according to my suggestion and test it against the original
problem you stated in this thread. It works. How do I know that? Because I did it a month ago.
-Adrian
BJ Freeman wrote:
> best way to prove this is to have a menu in a new app.
> point it to two different screens one in each app.
> try to get both screens to work with out error.
> even using your code.
>
> BJ Freeman sent the following on 12/17/2007 1:39 PM:
>
>>you did not say to change
>><decorator-screen name="main-decorator"
>>location="${parameters.mainDecoratorLocation}">
>>
>>so even your change will not work.
>>
>>Adrian Crum sent the following on 12/17/2007 1:32 PM:
>>
>>>That line wouldn't exist if you made the change I suggested.
>>>
>>>Make the code changes, THEN tell me what's wrong with it. Telling me
>>>what's already wrong with it is pointless - I already know the existing
>>>code doesn't work.
>>>
>>>
>>>BJ Freeman wrote:
>>>
>>>
>>>>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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
best way to prove this is to have a menu in a new app.
point it to two different screens one in each app.
try to get both screens to work with out error.
even using your code.
BJ Freeman sent the following on 12/17/2007 1:39 PM:
> you did not say to change
> <decorator-screen name="main-decorator"
> location="${parameters.mainDecoratorLocation}">
>
> so even your change will not work.
>
> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>> That line wouldn't exist if you made the change I suggested.
>>
>> Make the code changes, THEN tell me what's wrong with it. Telling me
>> what's already wrong with it is pointless - I already know the existing
>> code doesn't work.
>>
>>
>> BJ Freeman wrote:
>>
>>> 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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
you did not say to change
<decorator-screen name="main-decorator"
location="${parameters.mainDecoratorLocation}">
so even your change will not work.
Adrian Crum sent the following on 12/17/2007 1:32 PM:
> That line wouldn't exist if you made the change I suggested.
>
> Make the code changes, THEN tell me what's wrong with it. Telling me
> what's already wrong with it is pointless - I already know the existing
> code doesn't work.
>
>
> BJ Freeman wrote:
>
>> 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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
That line wouldn't exist if you made the change I suggested.
Make the code changes, THEN tell me what's wrong with it. Telling me what's already wrong with it is
pointless - I already know the existing code doesn't work.
BJ Freeman wrote:
> 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 <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.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.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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 <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.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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <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.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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
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.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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by Adrian Crum <ad...@hlmksw.com>.
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.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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
Re: mainDecoratorLocation was Include of controllers
Posted by BJ Freeman <bj...@free-man.net>.
I will still get the error since the parameters.mainDecoratorLocation
for that is in the web.xml for party.
BJ Freeman sent the following on 12/17/2007 12:23 PM:
> 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.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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>