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 <[EMAIL PROTECTED]> To: [email protected] 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 <[EMAIL PROTECTED]> >>>>To: [email protected] >>>>Sent: Saturday, December 15, 2007 12:19:27 PM >>>>Subject: Re: Include of controllers >>>> >>>> >>>>I was going thru the trunk and noticed this in all the controllers >>>> <include >>>>location="component://common/webcommon/WEB-INF/common-controller.xml"/> >>>> >>>>so there is a rule that says you can include a controller not in the >>>>same app. >>>> >>>> >>>>BJ Freeman sent the following on 11/10/2007 4:15 PM: >>>> >>>> >>>>>Almost. >>>>>when the included controller view calles a screen in the partymgr >>>> >>>>screen >>>> >>>> >>>>>, and that screen calls for a parm that is web.xml. the parm is not >>>>>availible for the screen and so fails. >>>>> >>>>>At this time, the way I handle this is to put the parm in my Web.xml. >>>>> >>>>>My suggestions was that if a call is made to a parm that would be in >>>> >>>>the >>>> >>>> >>>>>applications, in this case partymgr, web.xml, that widget looks up >>>> >>>>the >>>> >>>> >>>>>web.xml for that application to get it. >>>>> >>>>> >>>>>Chris Howe sent the following on 11/10/2007 2:23 PM: >>>>> >>>>> >>>>>>Okay, I've read through the thread. In that case, I might suggest >>>> >>>>to take a step back and look at what the two functionalities were >>>>designed to accomplish. >>>> >>>>>>Creating the mainDecoratorLocation variable in the web.xml was >>>> >>>>designed for _screen reuse. the include element in the controller.xml >>>>file >>>>was designed for request/response maintenance. >>>> >>>>>>With that in mind, you can include another controller in your custom >>>> >>>>application and then override the view with one that points to your >>>>application. If you wish to then include a screen from another >>>>application you can use the <include-screen> element in the screen >>>>widget and >>>>at the same time pass a parameters.mainDecoratorLocation to override the >>>>one gained from the web.xml context of the webapp being used. >>>> >>>> >>>>>>It appears that what BJ is suggesting would make the screen being >>>> >>>>called from the ofbiz application nonreusable except as decorated as it >>>>is in the ofbiz project which defeats the entire purpose of the >>>>mainDecoratorLocation variable. Do I follow correctly? >>>> >>>> >>>>>>----- Original Message ---- >>>>>>From: BJ Freeman <[EMAIL PROTECTED]> >>>>>>To: [email protected] >>>>>>Sent: Saturday, November 10, 2007 2:12:12 PM >>>>>>Subject: Re: Include of controllers >>>>>> >>>>>>Chris the discussion is about using the include in the controller. >>>>>>and that the current way of putting the locations of parameters used >>>> >>>>in >>>> >>>> >>>>>>the widgets for screen decorators is causing a problem >>>>>>In a lot of apps the location is called out in the web.xml >>>>>> <context-param> >>>>>> <param-name>mainDecoratorLocation</param-name> >>>>>> >>>><param-value>component://party/widget/partymgr/CommonScreens.xml</param-value> >>>> >>>> >>>>>> <description>The location of the main-decorator screen to use >>>> >>>>for >>>> >>>> >>>>>>this webapp; referred to as a context variable in screen def XML >>>>>>files.</description> >>>>>> </context-param> >>>>>> >>>>>>The suggeston is to take the location out to the web.xml and put in >>>> >>>>the >>>> >>>> >>>>>>widget like so. >>>>>> >>>>>><decorator-screen name="CommonPartyDecorator" >>>>>>location="component://party/widget/partymgr/CommonScreens.xml"> >>>>>> >>>>>> >>>>>> >>>>>>Chris Howe sent the following on 11/9/2007 9:14 PM: >>>>>> >>>>>> >>>>>>>I haven't been following the thread, but instead of setting it >>>>>> >>>>>>explicitly in the widgets section, you may prefer to define it in >>>> >>>>the actions >>>> >>>> >>>>>>section... >>>>>> >>>>>> >>>>>>><action> >>>>>>> <set field="parameters.mainDecoratorLocation" >>>>>> >>>>>>value="component://party/widget/partymgr/CommonScreens.xml"/> >>>>>> >>>>>>></action> >>>>>>><widget> >>>>>>> <include-screen name="splitScreen"/> >>>>>>></widget> >>>>>>>... >>>>>>> <decorator-screen name="CommonPartyDecorator" >>>>>> >>>>>>location="${parameters.mainDecoratorLocation}"> >>>>>> >>>>>>><screen name="splitScreen"> >>>>>>>... >>>>>>><widget> >>>>>>> >>>>>>></widget> >>>>>>>... >>>>>>>or something similar that it remains a variable so that you can >>>> >>>>later >>>> >>>> >>>>>>split the widget section out to be it's own screen so that it can >>>> >>>>be >>>> >>>> >>>>>>used with the decorator in another webapp. I don't know if the >>>> >>>>screens >>>> >>>> >>>>>>you're worried about here are that complex. This has been a >>>> >>>>better >>>> >>>> >>>>>>pattern for me. >>>>>> >>>>>> >>>>>>>----- Original Message ---- >>>>>>>From: BJ Freeman <[EMAIL PROTECTED]> >>>>>>>To: [email protected] >>>>>>>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. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > >
