Include of controllers
Locked
1234
1234
 
|
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 <[hidden email]> >>>>To: [hidden email] >>>>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 <[hidden email]> >>>>>>To: [hidden email] >>>>>>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 <[hidden email]> >>>>>>>To: [hidden email] >>>>>>>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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > |
|
|
In reply to this post by BJ Freeman
You two are talking about different issues. BJ is describing a pitfall that occurs when you use the <include> tag in the controller for a scenario that wasn't considered when the <include> tag was implemented in the controller.
----- Original Message ---- From: Adrian Crum <[hidden email]> To: [hidden email] Sent: Monday, December 17, 2007 11:33:43 AM Subject: Re: Include of controllers 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 >>>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 >>>>are trying to attach context to it. >>>> >>>>----- Original Message ---- >>>>From: BJ Freeman <[hidden email]> >>>>To: [hidden email] >>>>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 >>>>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 >>>>>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 >>>> >>>>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 <[hidden email]> >>>>>>To: [hidden email] >>>>>>Sent: Saturday, November 10, 2007 2:12:12 PM >>>>>>Subject: Re: Include of controllers >>>>>> >>>>>>Chris the discussion is about using the include in the >>>>>>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 >>>> >>>>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 <[hidden email]> >>>>>>>To: [hidden email] >>>>>>>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> >>>>>>> >>>> >>>> >>>> >>>>>>> <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 >>>> >>>>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 >>>>>>> >>>>>>>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 >>>> >>>>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 >>>>>> >>>>>>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 >>>> >>>>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 >>>> >>>>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 >>>>>>> >>>>>>>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 >>>>>>> >>>>>>>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 >>>> >>>>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 >>>>>>>>>>>>>> >>>>>> >>>>>> >>>>[component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]: >>>> >>>> >>>> >>>>>>>>>>>>>>java.lang.IllegalArgumentException: Could not find screen >>>> >>>>with >>>> >>>> >>>>>>>name >>>>>>> >>>>>>> >>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same file as >>>>>>> >>>>>>>screen >>>>>>> >>>>>>> >>>>>>>>>>>>>>with >>>>>>>>>>>>>>name [EditCommunicationEvent] (Could not find screen with >>>> >>>>name >>>> >>>> >>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same file as >>>>>>> >>>>>>>screen >>>>>>> >>>>>>> >>>>>>>>>>>>>>with >>>>>>>>>>>>>>name [EditCommunicationEvent]) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>BJ, >>>>>>>>>>>>>> >>>>>>>>>>>>>>Do you have any specific examples of what you're >>>>>>>>>>>>>> >>>>>>>>>>>>>>-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 >>>> >>>>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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > > |
|
|
If BJ supplies a patch as I described, then we'll see if it solves his problem. If it does, then
we're talking about the same issue. ;-) -Adrian Chris Howe wrote: > You two are talking about different issues. BJ is describing a pitfall that occurs when you use the <include> tag in the controller for a scenario that wasn't considered when the <include> tag was implemented in the controller. > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:33:43 AM > Subject: Re: Include of controllers > > > 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 <[hidden email]> >>>>>To: [hidden email] >>>>>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 <[hidden email]> >>>>>>>To: [hidden email] >>>>>>>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 <[hidden email]> >>>>>>>>To: [hidden email] >>>>>>>>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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> > > > > > |
|
|
i probably am not
I was going to move the location data for main-decorator from the web.xml to the actual widget files. Adrian Crum sent the following on 12/17/2007 9:46 AM: > If BJ supplies a patch as I described, then we'll see if it solves his > problem. If it does, then we're talking about the same issue. ;-) > > -Adrian > > Chris Howe wrote: > >> You two are talking about different issues. BJ is describing a >> pitfall that occurs when you use the <include> tag in the controller >> for a scenario that wasn't considered when the <include> tag was >> implemented in the controller. >> >> ----- Original Message ---- >> From: Adrian Crum <[hidden email]> >> To: [hidden email] >> Sent: Monday, December 17, 2007 11:33:43 AM >> Subject: Re: Include of controllers >> >> >> 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 <[hidden email]> >>>>>> To: [hidden email] >>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> >> >> >> > > > > |
|
|
In reply to this post by BJ Freeman
BJ's problem occurs because when he <include>s the party
controller and the catalog controller, he wants the requests/views from the party controller to have mainDecoratorLocation equal one place and the requests/views from the catalog controller to equal another. The only way for it to solve BJ's issue is to replace current ${parameters.mainDecoratorLocation} with ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or to remove the variable location altogether, thus breaking the ability call that screen from a custom application. Not simply provide a variable to <decororator-screen> location's that are empty. ----- Original Message ---- From: Adrian Crum <[hidden email]> To: [hidden email] Sent: Monday, December 17, 2007 11:46:26 AM Subject: Re: Include of controllers If BJ supplies a patch as I described, then we'll see if it solves his problem. If it does, then we're talking about the same issue. ;-) -Adrian Chris Howe wrote: > You two are talking about different issues. BJ is describing a pitfall that occurs when you use the <include> tag in the controller for a scenario that wasn't considered when the <include> tag was implemented in the controller. > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:33:43 AM > Subject: Re: Include of controllers > > > 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 > 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 > 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 >>>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 >>>>>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 <[hidden email]> >>>>>To: [hidden email] >>>>>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 >>>>> >>>>>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 >>>>>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 >>>>> >>>>>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 <[hidden email]> >>>>>>>To: [hidden email] >>>>>>>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 >>>>> >>>>>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 >>>>> >>>>>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 <[hidden email]> >>>>>>>>To: [hidden email] >>>>>>>>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> >>>>>>>> > > >>>>> >>>>>>>> <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 > > 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 >>>>> >>>>>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 >>>>> >>>>>with >>>>> >>>>> >>>>> >>>>>>>>name >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same file as > > the > >>>>>>>>screen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>>with >>>>>>>>>>>>>>>name [EditCommunicationEvent] (Could not find screen >>>>> >>>>>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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >> > > > > > |
|
|
In reply to this post by Adrian Crum
sorry just saw this email
i was going to replace location="${parameters.mainDecoratorLocation with the actual location as declared in each web.xml for an application. 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 <[hidden email]> >>>>> To: [hidden email] >>>>> 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 <[hidden email]> >>>>>>> To: [hidden email] >>>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> > > > > |
|
|
In reply to this post by cjhowe
Chris I have been able to call widget and forms thru a custom widget
with no errors when the ${parameters.mainDecoratorLocation} is replace by the actually location as defined in the web.xml Chris Howe sent the following on 12/17/2007 10:07 AM: > BJ's problem occurs because when he <include>s the party > controller and the catalog controller, he wants the requests/views from > the party controller to have mainDecoratorLocation equal one place and > the requests/views from the catalog controller to equal another. > > The only way for it to solve BJ's issue is to replace current ${parameters.mainDecoratorLocation} with ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or to remove the variable location altogether, thus breaking the ability call that screen from a custom application. Not simply provide a variable to <decororator-screen> location's that are empty. > > > > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:46:26 AM > Subject: Re: Include of controllers > > > If BJ supplies a patch as I described, then we'll see if it solves his > problem. If it does, then > we're talking about the same issue. ;-) > > -Adrian > > Chris Howe wrote: > >> You two are talking about different issues. BJ is describing a > pitfall that occurs when you use the <include> tag in the controller for a > scenario that wasn't considered when the <include> tag was implemented > in the controller. >> ----- Original Message ---- >> From: Adrian Crum <[hidden email]> >> To: [hidden email] >> Sent: Monday, December 17, 2007 11:33:43 AM >> Subject: Re: Include of controllers >> >> >> 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 <[hidden email]> >>>>>> To: [hidden email] >>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> >> >> > > > > > > > |
|
|
In reply to this post by cjhowe
I don't agree that that is the only way to solve the problem. I have suggested the CORRECT solution
to this problem ever since the beginning of this thread, but that solution is being ignored, and instead it is being replced with a kludge that tries to fix a SYMPTOM, and not the real problem. -Adrian Chris Howe wrote: > BJ's problem occurs because when he <include>s the party > controller and the catalog controller, he wants the requests/views from > the party controller to have mainDecoratorLocation equal one place and > the requests/views from the catalog controller to equal another. > > The only way for it to solve BJ's issue is to replace current ${parameters.mainDecoratorLocation} with ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or to remove the variable location altogether, thus breaking the ability call that screen from a custom application. Not simply provide a variable to <decororator-screen> location's that are empty. > > > > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:46:26 AM > Subject: Re: Include of controllers > > > If BJ supplies a patch as I described, then we'll see if it solves his > problem. If it does, then > we're talking about the same issue. ;-) > > -Adrian > > Chris Howe wrote: > > >>You two are talking about different issues. BJ is describing a > > pitfall that occurs when you use the <include> tag in the controller for a > scenario that wasn't considered when the <include> tag was implemented > in the controller. > >>----- Original Message ---- >>From: Adrian Crum <[hidden email]> >>To: [hidden email] >>Sent: Monday, December 17, 2007 11:33:43 AM >>Subject: Re: Include of controllers >> >> >>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 <[hidden email]> >>>>>>To: [hidden email] >>>>>>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 <[hidden email]> >>>>>>>>To: [hidden email] >>>>>>>>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 <[hidden email]> >>>>>>>>>To: [hidden email] >>>>>>>>>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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> >> >> > > > > > |
|
|
In reply to this post by BJ Freeman
I would agree with the solution you offered of sending the views to custom application screens that dictate how the controller is to be used.. BJ does not. BJ doesn't want to create any screens in his custom application.
----- Original Message ---- From: Adrian Crum <[hidden email]> To: [hidden email] Sent: Monday, December 17, 2007 12:20:23 PM Subject: Re: Include of controllers I don't agree that that is the only way to solve the problem. I have suggested the CORRECT solution to this problem ever since the beginning of this thread, but that solution is being ignored, and instead it is being replced with a kludge that tries to fix a SYMPTOM, and not the real problem. -Adrian Chris Howe wrote: > BJ's problem occurs because when he <include>s the party > controller and the catalog controller, he wants the requests/views from > the party controller to have mainDecoratorLocation equal one place and > the requests/views from the catalog controller to equal another. > > The only way for it to solve BJ's issue is to replace current ${parameters.mainDecoratorLocation} with ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or to remove the variable location altogether, thus breaking the ability call that screen from a custom application. Not simply provide a variable to <decororator-screen> location's that are empty. > > > > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:46:26 AM > Subject: Re: Include of controllers > > > If BJ supplies a patch as I described, then we'll see if it solves > problem. If it does, then > we're talking about the same issue. ;-) > > -Adrian > > Chris Howe wrote: > > >>You two are talking about different issues. BJ is describing a > > pitfall that occurs when you use the <include> tag in the controller > scenario that wasn't considered when the <include> tag was implemented > in the controller. > >>----- Original Message ---- >>From: Adrian Crum <[hidden email]> >>To: [hidden email] >>Sent: Monday, December 17, 2007 11:33:43 AM >>Subject: Re: Include of controllers >> >> >>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 >>>>>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 >>>>>>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 <[hidden email]> >>>>>>To: [hidden email] >>>>>>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 >>>>>> <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 >>>>>> >>>>>>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 >> >> 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 >>>>>>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 <[hidden email]> >>>>>>>>To: [hidden email] >>>>>>>>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 >>>>>>>>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 >>>>>> >>>>>>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 <[hidden email]> >>>>>>>>>To: [hidden email] >>>>>>>>>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> >>>>>>>>> > > >>>>>>>>> <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 >> >> 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 >> >> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> >> >> > > > > > |
|
|
In reply to this post by BJ Freeman
Yes, you can call widgets and forms through custom widgets with no errors by having a static screen decorator. The problem is, you end up with an OFBiz screen and not a custom screen. The entire reason to have a variable is so that you can customize the screen.
----- Original Message ---- From: BJ Freeman <[hidden email]> To: [hidden email] Sent: Monday, December 17, 2007 12:20:18 PM Subject: Re: Include of controllers Chris I have been able to call widget and forms thru a custom widget with no errors when the ${parameters.mainDecoratorLocation} is replace by the actually location as defined in the web.xml Chris Howe sent the following on 12/17/2007 10:07 AM: > BJ's problem occurs because when he <include>s the party > controller and the catalog controller, he wants the requests/views from > the party controller to have mainDecoratorLocation equal one place and > the requests/views from the catalog controller to equal another. > > The only way for it to solve BJ's issue is to replace current ${parameters.mainDecoratorLocation} with ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or to remove the variable location altogether, thus breaking the ability call that screen from a custom application. Not simply provide a variable to <decororator-screen> location's that are empty. > > > > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 11:46:26 AM > Subject: Re: Include of controllers > > > If BJ supplies a patch as I described, then we'll see if it solves > problem. If it does, then > we're talking about the same issue. ;-) > > -Adrian > > Chris Howe wrote: > >> You two are talking about different issues. BJ is describing a > pitfall that occurs when you use the <include> tag in the controller for a > scenario that wasn't considered when the <include> tag was implemented > in the controller. >> ----- Original Message ---- >> From: Adrian Crum <[hidden email]> >> To: [hidden email] >> Sent: Monday, December 17, 2007 11:33:43 AM >> Subject: Re: Include of controllers >> >> >> 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 >> 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 >>>> 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 >>>>> 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 >>>>>> 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 <[hidden email]> >>>>>> To: [hidden email] >>>>>> 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 >>>>>> <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 >>>>>> 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 >> 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 >>>>>> 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 >>>>>> 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 >> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 >> 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> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> <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" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>> 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 >>>>>> screens >>>>>> >>>>>> >>>>>> >>>>>>>> you're worried about here are that complex. This has been a >>>>>> better >>>>>> >>>>>> >>>>>> >>>>>>>> pattern for me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ----- Original Message ---- >>>>>>>>> From: BJ Freeman <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> 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> >>>>>>>>> > >>>>>>>>> <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" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >> 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 >>>>>>>>>>>> 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 >> to >> >>>>>> fix >>>>>> >>>>>> >>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> party manager screens. Including web.xml files will open >> 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 >> 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 >> 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 >> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find > screen >>>>>> with >>>>>> >>>>>> >>>>>> >>>>>>>>> name >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file >> the >> >>>>>>>>> screen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find screen > with >>>>>> name >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same file >> 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 >> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >> >> >> >> > > > > > > > |
|
|
In reply to this post by Adrian Crum
The problem is any screen that used
location="${parameters.mainDecoratorLocation} will can not be called from a remote controller that includes the controller for that app. so if myapp controller includes the products controller and that then brings up a view in products. it will not find the parameters.mainDecoratorLocation for products and will error. 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 <[hidden email]> >>>>> To: [hidden email] >>>>> 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 <[hidden email]> >>>>>>> To: [hidden email] >>>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> > > > > |
|
|
In reply to this post by cjhowe
If my suggestion is followed, then BJ can include all the controllers he wants and all of the
included screens will perform as expected - no additional work is needed. -Adrian Chris Howe wrote: > I would agree with the solution you offered of sending the views to custom application screens that dictate how the controller is to be used.. BJ does not. BJ doesn't want to create any screens in his custom application. > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 17, 2007 12:20:23 PM > Subject: Re: Include of controllers > > > I don't agree that that is the only way to solve the problem. I have > suggested the CORRECT solution > to this problem ever since the beginning of this thread, but that > solution is being ignored, and > instead it is being replced with a kludge that tries to fix a SYMPTOM, > and not the real problem. > > -Adrian > > Chris Howe wrote: > >>BJ's problem occurs because when he <include>s the party >>controller and the catalog controller, he wants the requests/views > > from > >>the party controller to have mainDecoratorLocation equal one place > > and > >>the requests/views from the catalog controller to equal another. >> >>The only way for it to solve BJ's issue is to replace current > > ${parameters.mainDecoratorLocation} with > ${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation} or > to remove the variable location altogether, thus breaking the ability > call that screen from a custom application. Not simply provide a variable > to <decororator-screen> location's that are empty. > >> >> >> >>----- Original Message ---- >>From: Adrian Crum <[hidden email]> >>To: [hidden email] >>Sent: Monday, December 17, 2007 11:46:26 AM >>Subject: Re: Include of controllers >> >> >>If BJ supplies a patch as I described, then we'll see if it solves > > his > >> problem. If it does, then >>we're talking about the same issue. ;-) >> >>-Adrian >> >>Chris Howe wrote: >> >> >> >>>You two are talking about different issues. BJ is describing a >> >> pitfall that occurs when you use the <include> tag in the controller > > for a > >> scenario that wasn't considered when the <include> tag was > > implemented > >> in the controller. >> >> >>>----- Original Message ---- >>>From: Adrian Crum <[hidden email]> >>>To: [hidden email] >>>Sent: Monday, December 17, 2007 11:33:43 AM >>>Subject: Re: Include of controllers >>> >>> >>>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 <[hidden email]> >>>>>>>To: [hidden email] >>>>>>>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 <[hidden email]> >>>>>>>>>To: [hidden email] >>>>>>>>>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 <[hidden email]> >>>>>>>>>>To: [hidden email] >>>>>>>>>>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. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>> >>> >>> >> >> >> >> > > > > > |
|
|
In reply to this post by BJ Freeman
Exactly. That's because the screen was designed poorly. If the products screen was fixed as I
suggested, then it would work as you would expect. BJ Freeman wrote: > The problem is any screen that used > location="${parameters.mainDecoratorLocation} > will can not be called from a remote controller that includes the > controller for that app. > so if myapp controller includes the products controller and that then > brings up a view in products. it will not find the > parameters.mainDecoratorLocation for products > and will error. > > 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 <[hidden email]> >>>>>>To: [hidden email] >>>>>>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 <[hidden email]> >>>>>>>>To: [hidden email] >>>>>>>>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 <[hidden email]> >>>>>>>>>To: [hidden email] >>>>>>>>>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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> >> > > |
|
|
Actually, it would be better if we stuck to the original example you gave - communication events in
the Party Manager component. Have you tried the solution I offerred? -Adrian Adrian Crum wrote: > Exactly. That's because the screen was designed poorly. If the products > screen was fixed as I suggested, then it would work as you would expect. > > BJ Freeman wrote: > >> The problem is any screen that used >> location="${parameters.mainDecoratorLocation} >> will can not be called from a remote controller that includes the >> controller for that app. >> so if myapp controller includes the products controller and that then >> brings up a view in products. it will not find the >> parameters.mainDecoratorLocation for products >> and will error. >> >> 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 <[hidden email]> >>>>>>> To: [hidden email] >>>>>>> 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 <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> 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 <[hidden email]> >>>>>>>>>> To: [hidden email] >>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> > > |
|
|
I agree with Chris' interpretation here, while you are right Adrian about
the sub decorators you're missing what BJ is trying to acheive. He wants to include the controllers from the base apps but not have to define his own mainDecoratorLocation for the screens from those apps. Regards Scott On 18/12/2007, Adrian Crum <[hidden email]> wrote: > > Actually, it would be better if we stuck to the original example you gave > - communication events in > the Party Manager component. Have you tried the solution I offerred? > > -Adrian > > Adrian Crum wrote: > > > Exactly. That's because the screen was designed poorly. If the products > > screen was fixed as I suggested, then it would work as you would expect. > > > > BJ Freeman wrote: > > > >> The problem is any screen that used > >> location="${parameters.mainDecoratorLocation} > >> will can not be called from a remote controller that includes the > >> controller for that app. > >> so if myapp controller includes the products controller and that then > >> brings up a view in products. it will not find the > >> parameters.mainDecoratorLocation for products > >> and will error. > >> > >> 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 <[hidden email]> > >>>>>>> To: [hidden email] > >>>>>>> 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 <[hidden email]> > >>>>>>>>> To: [hidden email] > >>>>>>>>> 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 <[hidden email]> > >>>>>>>>>> To: [hidden email] > >>>>>>>>>> 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. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > |
|
|
In reply to this post by Adrian Crum
Ok I will try to get my head around you solution.
:) Adrian Crum sent the following on 12/17/2007 10:42 AM: > Actually, it would be better if we stuck to the original example you > gave - communication events in the Party Manager component. Have you > tried the solution I offerred? > > -Adrian > > Adrian Crum wrote: > >> Exactly. That's because the screen was designed poorly. If the >> products screen was fixed as I suggested, then it would work as you >> would expect. >> >> BJ Freeman wrote: >> >>> The problem is any screen that used >>> location="${parameters.mainDecoratorLocation} >>> will can not be called from a remote controller that includes the >>> controller for that app. >>> so if myapp controller includes the products controller and that then >>> brings up a view in products. it will not find the >>> parameters.mainDecoratorLocation for products >>> and will error. >>> >>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 <[hidden email]> >>>>>>>>>> To: [hidden email] >>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>> To: [hidden email] >>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > > > |
|
|
In reply to this post by Adrian Crum
only shied away from it because I don't understand it yet
so will try to make it work with you suggestion. Adrian Crum sent the following on 12/17/2007 10:42 AM: > Actually, it would be better if we stuck to the original example you > gave - communication events in the Party Manager component. Have you > tried the solution I offerred? > > -Adrian > > Adrian Crum wrote: > >> Exactly. That's because the screen was designed poorly. If the >> products screen was fixed as I suggested, then it would work as you >> would expect. >> >> BJ Freeman wrote: >> >>> The problem is any screen that used >>> location="${parameters.mainDecoratorLocation} >>> will can not be called from a remote controller that includes the >>> controller for that app. >>> so if myapp controller includes the products controller and that then >>> brings up a view in products. it will not find the >>> parameters.mainDecoratorLocation for products >>> and will error. >>> >>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 <[hidden email]> >>>>>>>>>> To: [hidden email] >>>>>>>>>> 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 <[hidden email]> >>>>>>>>>>> To: [hidden email] >>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > > > |
|
|
In reply to this post by Scott Gray
The original intent of having the mainDecoratorLocation parameter was to be able to reuse OOTB
screens and have them decorated with your custom app's main decorator. If BJ wants to do something different than that, then yes - he'll need to do some extra work in his custom app. This thread started with a simple problem - BJ included the Party Manager component's controller.xml file in his custom app so he could reuse the party manager screens. That SHOULD work, but instead it generates errors. I looked at how the party manager screens were set up and I saw where the problem was - not in the controller.xml file or in the web.xml file, but in the design of the screens. They can't be reused - regardless of whether you try to reuse them via including a controller.xml file or by some other means. If BJ would try my suggestion, I believe it will solve his problem. We can argue about the correct solution all day, but it's just a waste of bandwidth until someone actually tries it. -Adrian Scott Gray wrote: > I agree with Chris' interpretation here, while you are right Adrian about > the sub decorators you're missing what BJ is trying to acheive. He wants to > include the controllers from the base apps but not have to define his own > mainDecoratorLocation for the screens from those apps. > > Regards > Scott > > On 18/12/2007, Adrian Crum <[hidden email]> wrote: > >>Actually, it would be better if we stuck to the original example you gave >>- communication events in >>the Party Manager component. Have you tried the solution I offerred? >> >>-Adrian >> >>Adrian Crum wrote: >> >> >>>Exactly. That's because the screen was designed poorly. If the products >>>screen was fixed as I suggested, then it would work as you would expect. >>> >>>BJ Freeman wrote: >>> >>> >>>>The problem is any screen that used >>>>location="${parameters.mainDecoratorLocation} >>>>will can not be called from a remote controller that includes the >>>>controller for that app. >>>>so if myapp controller includes the products controller and that then >>>>brings up a view in products. it will not find the >>>>parameters.mainDecoratorLocation for products >>>>and will error. >>>> >>>>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 <[hidden email]> >>>>>>>>>To: [hidden email] >>>>>>>>>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 <[hidden email]> >>>>>>>>>>>To: [hidden email] >>>>>>>>>>>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 <[hidden email]> >>>>>>>>>>>>To: [hidden email] >>>>>>>>>>>>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
|
|
In reply to this post by Adrian Crum
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 <[hidden email]> >>>>> To: [hidden email] >>>>> 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 <[hidden email]> >>>>>>> To: [hidden email] >>>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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
|
|
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 <[hidden email]> >>>>>> To: [hidden email] >>>>>> 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 <[hidden email]> >>>>>>>> To: [hidden email] >>>>>>>> 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 <[hidden email]> >>>>>>>>> To: [hidden email] >>>>>>>>> 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. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> >> > > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |