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 <[EMAIL PROTECTED]> wrote: >>>> Based on this, I can never see how even if I called from a custom app >>>> different screens in different apps how one main-decorator >>>> so I am not sure how this feature would work at all. >>>> >>>> Hence my original suggestion that is apps main-decorator be declared as >>>> application-mainDecoratorLocation >>>> this way I could include each apps mainDecoratorLocation and not have to >>>> worry >>>> >>>> >>>> BJ Freeman sent the following on 12/17/2007 12:55 PM: >>>>> I have a menu, no screens, that calls ListPartyCommEvents >>>>> this goes to the party controller to resolve. >>>>> the party controller uses it view for ListPartyCommEvents >>>>> It can not read the party web.xml so will error even with your changes. >>>>> >>>>> so lets say i put in a mainDecoratorLocation in my web xml and define it >>>>> like the one in the party commonscreens.xml >>>>> >>>>> so far so good. >>>>> >>>>> Now I call a screen in say Product. except the mainDecoratorLocation for >>>>> it has a different main-decorator. so all the requirements are not >>>>> defined in the party main-Decorator I have ported over. >>>>> >>>>> we still have a problem since all the apps main-decorators are not the >>>> same. >>>>> now if the main-decorators were all the same then I could use one >>>>> location in any of the apps and everything would be ok >>>>> >>>>> >>>>> >>>>> Adrian Crum sent the following on 12/17/2007 12:40 PM: >>>>>> 1. Move the CommonCommunicationEventDecorator screen to the >>>>>> communicationsscreens.xml file. >>>>>> 2. Change all >>>>>> <decorator-screen name="CommonCommunicationEventDecorator" >>>>>> location="${parameters.mainDecoratorLocation}"> >>>>>> >>>>>> to >>>>>> >>>>>> <decorator-screen name="CommonCommunicationEventDecorator" >>>>>> location="${parameters.communicationEventDecoratorLocation}"> >>>>>> >>>>>> Since parameters.communicationEventDecoratorLocation isn't defined >>>>>> anywhere, the location will evaluate to the current file: >>>>>> communicationsscreens.xml. All communication screens still work the >>>> same >>>>>> in Party Manager, but now you can reuse those screens in another app. >>>>>> >>>>>> When you use one of the communication screens in your custom app (via >>>>>> included controller.xml file or otherwise) the >>>>>> parameters.communicationEventDecoratorLocation still isn't defined >>>>>> anywhere, so it still evaluates to the current file: >>>>>> communicationsscreens.xml. The communication screen and the >>>>>> CommonCommunicationEventDecorator will both appear - decorated with >>>> your >>>>>> custom app's main decorator. >>>>>> >>>>>> (Optional) If someone didn't like the >>>> CommonCommunicationEventDecorator, >>>>>> then they could design their own and specify its location in >>>>>> parameters.communicationEventDecoratorLocation. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> BJ Freeman wrote: >>>>>> >>>>>>> Ok here is a real situation: >>>>>>> take the party/widgets/partymgr/commicationsscreens.xml >>>>>>> <decorator-screen name="CommonCommunicationEventDecorator" >>>>>>> location="${parameters.mainDecoratorLocation}"> >>>>>>> which is the CommonSreens.xml >>>>>>> which has >>>>>>> <decorator-screen name="main-decorator" >>>>>>> location="${parameters.mainDecoratorLocation}"> >>>>>>> >>>>>>> the main-decorator has >>>>>>> <include-screen name="GlobalDecorator" >>>>>>> location="component://common/widget/CommonScreens.xml"/> >>>>>>> >>>>>>> >>>>>>> how would the be with your example >>>>>>> >>>>>>> >>>>>>> >>>>>>> Adrian Crum sent the following on 12/17/2007 9:33 AM: >>>>>>> >>>>>>>> BJ, >>>>>>>> >>>>>>>> Go ahead and create one. I will work on it when I have time. >>>>>>>> >>>>>>>> To be sure we're all on the same page, the problem exists when >>>> screens >>>>>>>> are nested as follows: >>>>>>>> >>>>>>>> <screen name="GlobalDecorator"> >>>>>>>> <screen name="main-decorator"> >>>>>>>> <screen name="sub-decorator"> >>>>>>>> <screen name="actual-content"> >>>>>>>> ... >>>>>>>> </screen> >>>>>>>> </screen> >>>>>>>> </screen> >>>>>>>> </screen> >>>>>>>> >>>>>>>> and the location of the sub-decorator screen is defined as >>>>>>>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse >>>>>>>> the actual-content screen, errors are generated because >>>>>>>> <decorator-screen name="sub-decorator" >>>>>>>> location="${parameters.mainDecoratorLocation}"> evaluates to the >>>> custom >>>>>>>> app's main decorator xml file, and the sub-decorator screen doesn't >>>>>>>> exist there. >>>>>>>> >>>>>>>> The solution to the problem is to avoid using >>>>>>>> ${parameters.mainDecoratorLocation} as a location for sub-decorators >>>> and >>>>>>>> either have no location specified or use a different parameter for >>>> the >>>>>>>> sub-decorator's location - like ${subDecoratorLocation}. >>>>>>>> >>>>>>>> A good example of this approach is in AgreementScreens.xml in the >>>>>>>> Accounting component. All of the Agreement screens share a common >>>>>>>> sub-decorator (CommonAgreementDecorator) - and that decorator's >>>> location >>>>>>>> is specified as ${parameters.agreementDecoratorLocation}. The >>>>>>>> agreementDecoratorLocation parameter isn't defined anywhere, so the >>>>>>>> location= expression evaluates to an empty String - which causes the >>>>>>>> screen widget view handler to look for CommonAgreementDecorator in >>>> the >>>>>>>> existing file. >>>>>>>> >>>>>>>> A custom app that reuses one of the Agreement screens will only need >>>> to >>>>>>>> specify the mainDecoratorLocation parameter. Since no >>>>>>>> agreementDecoratorLocation parameter is defined in the custom app, >>>> the >>>>>>>> sub-decorator in AgreementScreens.xml is used (same as above). If a >>>>>>>> custom app wanted to have a custom sub-decorator, then it can specify >>>>>>>> that decorator's location in the agreementDecoratorLocation >>>> parameter. >>>>>>>> -Adrian >>>>>>>> >>>>>>>> BJ Freeman wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I agree, it is not a controller or web.xml issue. However it is when >>>> it >>>>>>>>> shows up. >>>>>>>>> I will change them as I come along also. >>>>>>>>> thanks, that is all I wanted to know. >>>>>>>>> do you want to create a jira so I can submit changes? >>>>>>>>> >>>>>>>>> Adrian Crum sent the following on 12/17/2007 7:57 AM: >>>>>>>>> >>>>>>>>> >>>>>>>>>> As I mentioned before, the problem is with the coding style on some >>>>>>>>>> screens, not with the controller or web.xml files. I recently >>>> changed >>>>>>>>>> some of the accounting screens to correct this error. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> BJ Freeman wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I am not really, trying to attach the context as a whole. >>>>>>>>>>> only trying to get the mainDecoratorLocation >>>>>>>>>>> which is stored as a context in web.xml. >>>>>>>>>>> The problem is if I put mainDecoratorLocation, in my web.xml >>>>>>>>>>> then all applications I call thru my controller, or the included >>>>>>>>>>> ones, >>>>>>>>>>> will use my mainDecoratorLocation full path. >>>>>>>>>>> Maybe the solution is to put the main-decorator for all apps in >>>> the >>>>>>>>>>> framework/commons >>>>>>>>>>> then like in many of the application they have specific decorators >>>>>>>>>>> that >>>>>>>>>>> include the main-decorator. >>>>>>>>>>> the problems is how to fill in the actions, etcetera >>>>>>>>>>> >>>>>>>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> All the <include> does is grab some xml elements from the >>>> location >>>>>>>>>>>> described. Theoretically, It doesn't even need to be from the >>>> same >>>>>>>>>>>> server, much less the same app (may have interesting >>>> possibilities >>>>>>>>>>>> BTW). This is why I'm having such a hard time understanding why >>>> you >>>>>>>>>>>> are trying to attach context to it. >>>>>>>>>>>> >>>>>>>>>>>> ----- Original Message ---- >>>>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]> >>>>>>>>>>>> To: dev@ofbiz.apache.org >>>>>>>>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM >>>>>>>>>>>> Subject: Re: Include of controllers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I was going thru the trunk and noticed this in all the >>>> controllers >>>>>>>>>>>> <include >>>>>>>>>>>> location="component://common/webcommon/WEB-INF/common- >>>> controller.xml"/> >>>>>>>>>>>> so there is a rule that says you can include a controller not in >>>> the >>>>>>>>>>>> same app. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Almost. >>>>>>>>>>>>> when the included controller view calles a screen in the >>>> partymgr >>>>>>>>>>>> screen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> , and that screen calls for a parm that is web.xml. the parm is >>>> not >>>>>>>>>>>>> availible for the screen and so fails. >>>>>>>>>>>>> >>>>>>>>>>>>> At this time, the way I handle this is to put the parm in my >>>>>>>>>>>>> Web.xml. >>>>>>>>>>>>> >>>>>>>>>>>>> My suggestions was that if a call is made to a parm that would >>>>>>>>>>>>> be in >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> applications, in this case partymgr, web.xml, that widget looks >>>> up >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> web.xml for that application to get it. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Chris Howe sent the following on 11/10/2007 2:23 PM: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Okay, I've read through the thread. In that case, I might >>>> suggest >>>>>>>>>>>> to take a step back and look at what the two functionalities were >>>>>>>>>>>> designed to accomplish. >>>>>>>>>>>> >>>>>>>>>>>>>> Creating the mainDecoratorLocation variable in the web.xml was >>>>>>>>>>>> designed for _screen reuse. the include element in the >>>>>>>>>>>> controller.xml >>>>>>>>>>>> file >>>>>>>>>>>> was designed for request/response maintenance. >>>>>>>>>>>> >>>>>>>>>>>>>> With that in mind, you can include another controller in your >>>>>>>>>>>>>> custom >>>>>>>>>>>> application and then override the view with one that points to >>>> your >>>>>>>>>>>> application. If you wish to then include a screen from another >>>>>>>>>>>> application you can use the <include-screen> element in the >>>> screen >>>>>>>>>>>> widget and >>>>>>>>>>>> at the same time pass a parameters.mainDecoratorLocation to >>>>>>>>>>>> override the >>>>>>>>>>>> one gained from the web.xml context of the webapp being used. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> It appears that what BJ is suggesting would make the screen >>>> being >>>>>>>>>>>> called from the ofbiz application nonreusable except as decorated >>>>>>>>>>>> as it >>>>>>>>>>>> is in the ofbiz project which defeats the entire purpose of the >>>>>>>>>>>> mainDecoratorLocation variable. Do I follow correctly? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ---- >>>>>>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]> >>>>>>>>>>>>>> To: dev@ofbiz.apache.org >>>>>>>>>>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM >>>>>>>>>>>>>> Subject: Re: Include of controllers >>>>>>>>>>>>>> >>>>>>>>>>>>>> Chris the discussion is about using the include in the >>>> controller. >>>>>>>>>>>>>> and that the current way of putting the locations of parameters >>>>>>>>>>>>>> used >>>>>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> the widgets for screen decorators is causing a problem >>>>>>>>>>>>>> In a lot of apps the location is called out in the web.xml >>>>>>>>>>>>>> <context-param> >>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name> >>>>>>>>>>>>>> >>>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value> >>>>>>>>>>>> >>>>>>>>>>>>>> <description>The location of the main-decorator screen to use >>>>>>>>>>>> for >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> this webapp; referred to as a context variable in screen def >>>> XML >>>>>>>>>>>>>> files.</description> >>>>>>>>>>>>>> </context-param> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The suggeston is to take the location out to the web.xml and >>>>>>>>>>>>>> put in >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> widget like so. >>>>>>>>>>>>>> >>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator" >>>>>>>>>>>>>> location="component://party/widget/partymgr/CommonScreens.xml"> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I haven't been following the thread, but instead of setting it >>>>>>>>>>>>>> explicitly in the widgets section, you may prefer to define it >>>> in >>>>>>>>>>>> the actions >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> section... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> <action> >>>>>>>>>>>>>>> <set field="parameters.mainDecoratorLocation" >>>>>>>>>>>>>> value="component://party/widget/partymgr/CommonScreens.xml"/> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> </action> >>>>>>>>>>>>>>> <widget> >>>>>>>>>>>>>>> <include-screen name="splitScreen"/> >>>>>>>>>>>>>>> </widget> >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator" >>>>>>>>>>>>>> location="${parameters.mainDecoratorLocation}"> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> <screen name="splitScreen"> >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> <widget> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> </widget> >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> or something similar that it remains a variable so that you >>>> can >>>>>>>>>>>> later >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> split the widget section out to be it's own screen so that it >>>> can >>>>>>>>>>>> be >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> used with the decorator in another webapp. I don't know if the >>>>>>>>>>>> screens >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> you're worried about here are that complex. This has been a >>>>>>>>>>>> better >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> pattern for me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ----- Original Message ---- >>>>>>>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]> >>>>>>>>>>>>>>> To: dev@ofbiz.apache.org >>>>>>>>>>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM >>>>>>>>>>>>>>> Subject: Re: Include of controllers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just want to make sure we are all on the same page >>>>>>>>>>>>>>> in a widget screen >>>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator" >>>>>>>>>>>>>>> location="${parameters.mainDecoratorLocation}"> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> parameters.mainDecoratorLocation is in the Web.xml >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <context-param> >>>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name> >>>>>>>>>>>>>>> >>>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value> >>>>>>>>>>>> >>>>>>>>>>>>>>> <description>The location of the main-decorator screen to use >>>>>>>>>>>> for >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> this webapp; referred to as a context variable in screen def >>>> XML >>>>>>>>>>>>>>> files.</description> >>>>>>>>>>>>>>> </context-param> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> so to "fix" >>>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator" >>>>>>>>>>>>>>> >>>> location="component://party/widget/partymgr/CommonScreens.xml"> >>>>>>>>>>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ok so the code that allows the context to be used in the >>>> web.xml >>>>>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> being depreciated? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BJ, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Nothing is being reversed. You have pointed out a weakness >>>>>>>>>>>>>>>>> in how >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> some of the party manager screens are set up (they can't be >>>>>>>>>>>>>> reused). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> have confirmed they have a problem. So submitting a patch >>>> FIXES >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> issue - it doesn't reverse anything. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BJ Freeman wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I will not submit a patch for what I am proposing, like a >>>>>>>>>>>>>>>>>> lot of >>>>>>>>>>>>>> my >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> code, it stays in the applications I am doing. >>>>>>>>>>>>>>>>>> and since someone else put effort into what is in ofbiz now >>>>>>>>>>>>>>>>>> I do not plan to put effort into reversing it. >>>>>>>>>>>>>>>>>> :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BJ, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As I mentioned before, I believe it would be better/easier >>>> to >>>>>>>>>>>> fix >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> party manager screens. Including web.xml files will open >>>> up a >>>>>>>>>>>> big >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> can of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> worms. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> BJ Freeman wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hans: >>>>>>>>>>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator >>>> location >>>>>>>>>>>> in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> context in web.xml >>>>>>>>>>>>>>>>>>>> this was done by someone else and is a standard through >>>>>>>>>>>>>>>>>>>> ofbiz >>>>>>>>>>>> as >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> far as >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> i can tell. >>>>>>>>>>>>>>>>>>>> I take the path of least resistance. >>>>>>>>>>>>>>>>>>>> Since it is possible to put context in the web.xml and >>>>>>>>>>>>>>>>>>>> someone >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> put a >>>>>>>>>>>>>>>>>>>> lot of effort into refactoring ofbiz to this standard, I >>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>> no >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> intention of undoing it. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> so my focus for my code will be to have the web.xmlincluded >>>>>>>>>>>> as >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> well, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> unless the powers to be say there is going to be a change >>>> in >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> best >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> practices. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Bj, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> request (or provide a patch) that the >>>>>>>>>>>>>>>>>>>>> CommonCommunicationEventDecorator >>>>>>>>>>>>>>>>>>>>> is moved to the xml file as defined in the web.xml >>>>>>>>>>>>>>>>>>>>> parameter. >>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> request that the 'location' parameter is defined in the >>>>>>>>>>>> screen >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> you are >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> using. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Then you can use this screen in your own application >>>> using >>>>>>>>>>>> your >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> own >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> decorator. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>> Hans >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I have a controller.xml >>>>>>>>>>>>>>>>>>>>>> it has the include for the partymgr in it. >>>>>>>>>>>>>>>>>>>>>> I have a menu widget that calls the partmgr >>>>>>>>>>>>>>>>>>>>>> I have the PartymgrDecoratorLocation in my web.xml >>>>>>>>>>>>>>>>>>>>>> so I get to the find screen OK. >>>>>>>>>>>>>>>>>>>>>> I have a few others in my web.xml as well. >>>>>>>>>>>>>>>>>>>>>> so I can navigate. >>>>>>>>>>>>>>>>>>>>>> however if you don't have these in your web.xml that is >>>> in >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> same >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> directory as the controller.xml you are using >>>>>>>>>>>>>>>>>>>>>> https://localhost:8443/myapp/control/partymgr >>>>>>>>>>>>>>>>>>>>>> then you get messages like this. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> org.ofbiz.base.util.GeneralException: Error rendering >>>>>>>>>>>>>>>>>>>>>> screen >>>>>>>>>>>>>>>>>>>>>> >>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find >>>> screen >>>>>>>>>>>> with >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> name >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> screen >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find screen >>>> with >>>>>>>>>>>> name >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file as >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> screen >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> name [EditCommunicationEvent]) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> BJ, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Do you have any specific examples of what you're >>>>>>>>>>>>>>>>>>>>>> describing? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -Adrian >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:59 PM: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> sorry not a complete thougt >>>>>>>>>>>>>>>>>>>>>>> This is not a real bug. >>>>>>>>>>>>>>>>>>>>>>> when you included another contorller >>>>>>>>>>>>>>>>>>>>>>> and there is a commonscreen.xml defined in the web.xmlof >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> calling >>>>>>>>>>>>>>>>>>>>>>> controller application it causes an error. >>>>>>>>>>>>>>>>>>>>>>> so maybe puttting the application name before >>>>>>>>>>>> commonescreens >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eliminate that. >>>>>>>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This is not a real bug. >>>>>>>>>>>>>>>>>>>>>>>> when you included another contorller >>>>>>>>>>>>>>>>>>>>>>>> and it has a commonscreen.xml >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> another is that when the the other widget from the >>>>>>>>>>>> included >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> controller >>>>>>>>>>>>>>>>>>>>>>>> calls for a context that is in the web.xml of that >>>>>>>>>>>>>>> application. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> it is not found. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>> >> >> >> > > > >