Include of controllers
Locked
1234
1234
 
|
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
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> > > <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 > 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 >>>>>>>> > >>>>>>>> >>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> >>> >>> >> >> > > > > > > |
|
|
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
Hello everyone
I finally got my domains back and my email sorted out. What a hassle. Skip |
|
|
So does this mean you're not going to be stupid anymore? :-p
Scott On 14/11/2007, skip@thedevers <[hidden email]> wrote: > Hello everyone > > I finally got my domains back and my email sorted out. What a hassle. > > Skip > > |
|
|
Lol
Well, I guess I am still stupid, but my penance time is now up. Skip -----Original Message----- From: Scott Gray [mailto:[hidden email]] Sent: Tuesday, November 13, 2007 6:03 PM To: [hidden email] Subject: Re: Domain problem solved So does this mean you're not going to be stupid anymore? :-p Scott On 14/11/2007, skip@thedevers <[hidden email]> wrote: > Hello everyone > > I finally got my domains back and my email sorted out. What a hassle. > > Skip > > |
|
|
In reply to this post by SkipDever
so how long is your password
I recommend over 15 characters. alphanumeric upperlower with punchuation. skip@thedevers sent the following on 11/13/2007 5:54 PM: > Hello everyone > > I finally got my domains back and my email sorted out. What a hassle. > > Skip > > > > |
|
|
My is now 14 and a mix of all these starting with a random generated Unix
password. I have "learnt" my lesson well. -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: Tuesday, November 13, 2007 6:23 PM To: [hidden email] Subject: Re: Domain problem solved so how long is your password I recommend over 15 characters. alphanumeric upperlower with punchuation. skip@thedevers sent the following on 11/13/2007 5:54 PM: > Hello everyone > > I finally got my domains back and my email sorted out. What a hassle. > > Skip > > > > |
|
|
In reply to this post by BJ Freeman
It never occured to me that someone would actually try to steal a stupid
worthless (except to me) set of domains. Skip -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: Tuesday, November 13, 2007 6:23 PM To: [hidden email] Subject: Re: Domain problem solved so how long is your password I recommend over 15 characters. alphanumeric upperlower with punchuation. skip@thedevers sent the following on 11/13/2007 5:54 PM: > Hello everyone > > I finally got my domains back and my email sorted out. What a hassle. > > Skip > > > > |
|
|
being an ex hacker, it is sometime just to tell another hacker you did it.
skip@thedevers sent the following on 11/13/2007 6:57 PM: > It never occured to me that someone would actually try to steal a stupid > worthless (except to me) set of domains. > > Skip > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: Tuesday, November 13, 2007 6:23 PM > To: [hidden email] > Subject: Re: Domain problem solved > > > so how long is your password > I recommend over 15 characters. alphanumeric upperlower with punchuation. > > > skip@thedevers sent the following on 11/13/2007 5:54 PM: >> Hello everyone >> >> I finally got my domains back and my email sorted out. What a hassle. >> >> Skip >> >> >> >> > > > > |
|
|
BJ,
You were a reverse-engineer? You dig operating systems and kernels? Do compilers and de-compilers? Wow. It's hard to find people like you. Let me know your areas of expertise? I've been searching for years. As for Skip's password thing, maybe he could just use PKI. I usually keep my password mile long, completely random with alphanumeric characters, such that humans can hardly even type it. I keep that password written somewhere safe, say in a thumbdrive stored in a safe box. Then I use only my personal key to access the server, which holds a copy of my public key, of course. Jonathon BJ Freeman wrote: > being an ex hacker, it is sometime just to tell another hacker you did it. > > > skip@thedevers sent the following on 11/13/2007 6:57 PM: >> It never occured to me that someone would actually try to steal a stupid >> worthless (except to me) set of domains. >> >> Skip >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: Tuesday, November 13, 2007 6:23 PM >> To: [hidden email] >> Subject: Re: Domain problem solved >> >> >> so how long is your password >> I recommend over 15 characters. alphanumeric upperlower with punchuation. >> >> >> skip@thedevers sent the following on 11/13/2007 5:54 PM: >>> Hello everyone >>> >>> I finally got my domains back and my email sorted out. What a hassle. >>> >>> Skip >>> >>> >>> >>> >> >> >> > > |
|
|
It was probably BJ that hacked my account. Funny guy. :)
I, on the other hand, do write operating systems and compilers. I have not however ever yet done a de-compiler. I am getting PKI. Someone turned me on to it already. My passwords are all now 12 -14 bytes long using two Unix generated random passwords concatenated and currently stored in a plain text file on my machine. Now I gotta get it all into PKI. Skip -----Original Message----- From: Jonathon -- Improov [mailto:[hidden email]] Sent: Wednesday, November 14, 2007 7:40 PM To: [hidden email] Subject: Re: Domain problem solved BJ, You were a reverse-engineer? You dig operating systems and kernels? Do compilers and de-compilers? Wow. It's hard to find people like you. Let me know your areas of expertise? I've been searching for years. As for Skip's password thing, maybe he could just use PKI. I usually keep my password mile long, completely random with alphanumeric characters, such that humans can hardly even type it. I keep that password written somewhere safe, say in a thumbdrive stored in a safe box. Then I use only my personal key to access the server, which holds a copy of my public key, of course. Jonathon BJ Freeman wrote: > being an ex hacker, it is sometime just to tell another hacker you did it. > > > skip@thedevers sent the following on 11/13/2007 6:57 PM: >> It never occured to me that someone would actually try to steal a stupid >> worthless (except to me) set of domains. >> >> Skip >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: Tuesday, November 13, 2007 6:23 PM >> To: [hidden email] >> Subject: Re: Domain problem solved >> >> >> so how long is your password >> I recommend over 15 characters. alphanumeric upperlower with punchuation. >> >> >> skip@thedevers sent the following on 11/13/2007 5:54 PM: >>> Hello everyone >>> >>> I finally got my domains back and my email sorted out. What a hassle. >>> >>> Skip >>> >>> >>> >>> >> >> >> > > |
|
|
Skip,
Glad you got into PKI! You wouldn't believe how hard it is to convince many of my clients to use PKI. They continue to use short dictionary words for server access passwords, and continue to get hacked every now and then. Yeah, it does mean I continue to get service contracts. Such is the world today. Oh well. No, I am *not* a hacker, and never will be. I did hack a copy-protected game some 15 years ago, but that's juvenile delinquency, is all. :P You'll really enjoy PKI, I assure you. :) Now, if you could help convince my clients... Jonathon skip@thedevers wrote: > It was probably BJ that hacked my account. Funny guy. :) > > I, on the other hand, do write operating systems and compilers. I have not > however ever yet done a de-compiler. > > I am getting PKI. Someone turned me on to it already. My passwords are all > now 12 -14 bytes long using two Unix generated random passwords concatenated > and currently stored in a plain text file on my machine. > > Now I gotta get it all into PKI. > > Skip > > -----Original Message----- > From: Jonathon -- Improov [mailto:[hidden email]] > Sent: Wednesday, November 14, 2007 7:40 PM > To: [hidden email] > Subject: Re: Domain problem solved > > > BJ, > > You were a reverse-engineer? You dig operating systems and kernels? Do > compilers and de-compilers? > Wow. It's hard to find people like you. Let me know your areas of expertise? > I've been searching > for years. > > As for Skip's password thing, maybe he could just use PKI. I usually keep my > password mile long, > completely random with alphanumeric characters, such that humans can hardly > even type it. I keep > that password written somewhere safe, say in a thumbdrive stored in a safe > box. > > Then I use only my personal key to access the server, which holds a copy of > my public key, of course. > > Jonathon > > BJ Freeman wrote: >> being an ex hacker, it is sometime just to tell another hacker you did it. >> >> >> skip@thedevers sent the following on 11/13/2007 6:57 PM: >>> It never occured to me that someone would actually try to steal a stupid >>> worthless (except to me) set of domains. >>> >>> Skip >>> >>> -----Original Message----- >>> From: BJ Freeman [mailto:[hidden email]] >>> Sent: Tuesday, November 13, 2007 6:23 PM >>> To: [hidden email] >>> Subject: Re: Domain problem solved >>> >>> >>> so how long is your password >>> I recommend over 15 characters. alphanumeric upperlower with punchuation. >>> >>> >>> skip@thedevers sent the following on 11/13/2007 5:54 PM: >>>> Hello everyone >>>> >>>> I finally got my domains back and my email sorted out. What a hassle. >>>> >>>> Skip >>>> >>>> >>>> >>>> >>> >>> >> > > > |
|
|
In reply to this post by BJ Freeman
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
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 >> 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 >> 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 >>>> 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 >>>>> 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 >>> 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 >>> 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 >>> 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 >>> 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 >>>>>>>>>>> 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 >>>>>>>>>>>> controller >>>>>>>>>>>> calls for a context that is in the web.xml of that >>> application. >>>>>>>>>>>> it is not found. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> >>> >>> >>> >> >> >> >> >> > > > |
|
|
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
The common-controller.xml should not use "main-decorator", or that would force every webapp in
OFBiz (if they include this file) to use a "main-decorator" compatible with webcommon screens. You brought up a good point. I'm now wondering if we should just get component://common/widget/CommonScreens.xml#requirePasswordChange to use GlobalDecorator instead of main-decorator. Jonathon BJ Freeman wrote: > 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. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > |
|
|
the other option is not to use the context
location="${parameters.mainDecoratorLocation}" and put it in the file like location="component://product/widget/catalog/CatalogCommonScreens.xml" in the screens this way don't have the problem at all. Jonathon -- Improov sent the following on 12/15/2007 4:26 PM: > The common-controller.xml should not use "main-decorator", or that would > force every webapp in OFBiz (if they include this file) to use a > "main-decorator" compatible with webcommon screens. > > You brought up a good point. I'm now wondering if we should just get > component://common/widget/CommonScreens.xml#requirePasswordChange to use > GlobalDecorator instead of main-decorator. > > Jonathon > > BJ Freeman wrote: >> 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
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, 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 |