Include of controllers
Locked
1234
1234
 
|
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. |
|
|
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 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 understand now, thank you for the clarification.
You would have to create your own CommonCommunicationEventDecorator decorator in your component's CommonScreens.xml file. At first glance, it appears the CommunicationScreens.xml file should contain the CommonCommunicationEventDecorator screen. That would make the screens easier to reuse. -Adrian 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. >>> >>> >>> >>> >> >> >> > |
|
|
or if the web.xml context is allowed the lookup should include the
web.xml for that component. Adrian Crum sent the following on 11/7/2007 1:57 PM: > I understand now, thank you for the clarification. > > You would have to create your own CommonCommunicationEventDecorator > decorator in your component's CommonScreens.xml file. > > At first glance, it appears the CommunicationScreens.xml file should > contain the CommonCommunicationEventDecorator screen. That would make > the screens easier to reuse. > > -Adrian > > 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. >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > > |
|
|
It all depends on what you're trying to accomplish and how to tackle it.
It appears from your emails that you're including the party manager controller.xml file in a custom app. That is an easy way to gain access to party manager screens within the custom app. But you'll run into problems doing it that way. Another way to approach it is to set up the requests and view maps in your custom app's controller.xml file that point to the screen definitions in the party manager component. From my perspective, that will give you more control. Either way, you'll have a problem with these "sub-decorator" screens. How you handle that issue depends on what your trying to achieve. If you want to use the same decorator screens, then you'll have to C&P them into your custom app's CommonScreens.xml file. If you don't want to use them, then just create empty decorator screens in your custom app's CommonScreens.xml file. -Adrian BJ Freeman wrote: > or if the web.xml context is allowed the lookup should include the > web.xml for that component. > > > > Adrian Crum sent the following on 11/7/2007 1:57 PM: > >>I understand now, thank you for the clarification. >> >>You would have to create your own CommonCommunicationEventDecorator >>decorator in your component's CommonScreens.xml file. >> >>At first glance, it appears the CommunicationScreens.xml file should >>contain the CommonCommunicationEventDecorator screen. That would make >>the screens easier to reuse. >> >>-Adrian >> >>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. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >> >> > |
|
|
you missed something
I can simply copy paste the Context into my web.xml since these are defined in each apps web.xml. I am pointing out that what ever is reading the controller in a application should also read the web.xml contexts. This would make it so there is no need to copy anything. Adrian Crum sent the following on 11/7/2007 2:19 PM: > It all depends on what you're trying to accomplish and how to tackle it. > > It appears from your emails that you're including the party manager > controller.xml file in a custom app. That is an easy way to gain access > to party manager screens within the custom app. But you'll run into > problems doing it that way. > > Another way to approach it is to set up the requests and view maps in > your custom app's controller.xml file that point to the screen > definitions in the party manager component. From my perspective, that > will give you more control. > > Either way, you'll have a problem with these "sub-decorator" screens. > How you handle that issue depends on what your trying to achieve. If you > want to use the same decorator screens, then you'll have to C&P them > into your custom app's CommonScreens.xml file. If you don't want to use > them, then just create empty decorator screens in your custom app's > CommonScreens.xml file. > > -Adrian > > BJ Freeman wrote: > >> or if the web.xml context is allowed the lookup should include the >> web.xml for that component. >> >> >> >> Adrian Crum sent the following on 11/7/2007 1:57 PM: >> >>> I understand now, thank you for the clarification. >>> >>> You would have to create your own CommonCommunicationEventDecorator >>> decorator in your component's CommonScreens.xml file. >>> >>> At first glance, it appears the CommunicationScreens.xml file should >>> contain the CommonCommunicationEventDecorator screen. That would make >>> the screens easier to reuse. >>> >>> -Adrian >>> >>> 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. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> >> > > > > |
|
|
Are you saying this:
if you include an external controller.xml file in your app's controller.xml file, then there should be a way to include the external web.xml in your app's web.xml file too? In this particular scenario, I think there is a better way to solve the problem: In the party manager component, move the CommonCommunicationEventDecorator screen definition into the CommunicationScreens.xml file, then change the lines that say <decorator-screen name="CommonCommunicationEventDecorator" location="${parameters.mainDecoratorLocation}"> to <decorator-screen name="CommonCommunicationEventDecorator" location="${parameters.communicationDecoratorLocation}"> That way you can reuse the communication screens as-is and they will default to the OOTB decorator screen, OR you can use your own decorator screen by defining the location of communicationDecoratorLocation in your app's web.xml file (just like mainDecoratorLocation). If that solves your problem, then create a patch and I will review/commit it. -Adrian BJ Freeman wrote: > you missed something > I can simply copy paste the Context into my web.xml since these are > defined in each apps web.xml. > > I am pointing out that what ever is reading the controller in a > application should also read the web.xml contexts. > This would make it so there is no need to copy anything. > > Adrian Crum sent the following on 11/7/2007 2:19 PM: > >>It all depends on what you're trying to accomplish and how to tackle it. >> >>It appears from your emails that you're including the party manager >>controller.xml file in a custom app. That is an easy way to gain access >>to party manager screens within the custom app. But you'll run into >>problems doing it that way. >> >>Another way to approach it is to set up the requests and view maps in >>your custom app's controller.xml file that point to the screen >>definitions in the party manager component. From my perspective, that >>will give you more control. >> >>Either way, you'll have a problem with these "sub-decorator" screens. >>How you handle that issue depends on what your trying to achieve. If you >>want to use the same decorator screens, then you'll have to C&P them >>into your custom app's CommonScreens.xml file. If you don't want to use >>them, then just create empty decorator screens in your custom app's >>CommonScreens.xml file. >> >>-Adrian >> >>BJ Freeman wrote: >> >> >>>or if the web.xml context is allowed the lookup should include the >>>web.xml for that component. >>> >>> >>> >>>Adrian Crum sent the following on 11/7/2007 1:57 PM: >>> >>> >>>>I understand now, thank you for the clarification. >>>> >>>>You would have to create your own CommonCommunicationEventDecorator >>>>decorator in your component's CommonScreens.xml file. >>>> >>>>At first glance, it appears the CommunicationScreens.xml file should >>>>contain the CommonCommunicationEventDecorator screen. That would make >>>>the screens easier to reuse. >>>> >>>>-Adrian >>>> >>>>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
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. > >> > >> > >> > >> > > > > > > > http://Antwebsystems.com : OFBiz Quality support for competitive rates. |
|
|
In reply to this post by Adrian Crum
yes include the web.xml also
before you create a patch make sure it is best practices and it will be folllowed after all they were that way then the context directive started being used. if no one is going to follow this practice you will be patching till you know what freezes over. so right now you have all the application and those in the frame work to patch. Adrian Crum sent the following on 11/7/2007 3:10 PM: > Are you saying this: > > if you include an external controller.xml file in your app's > controller.xml file, then there should be a way to include the external > web.xml in your app's web.xml file too? > > In this particular scenario, I think there is a better way to solve the > problem: > > In the party manager component, move the > CommonCommunicationEventDecorator screen definition into the > CommunicationScreens.xml file, then change the lines that say > > <decorator-screen name="CommonCommunicationEventDecorator" > location="${parameters.mainDecoratorLocation}"> > > to > > <decorator-screen name="CommonCommunicationEventDecorator" > location="${parameters.communicationDecoratorLocation}"> > > That way you can reuse the communication screens as-is and they will > default to the OOTB decorator screen, OR you can use your own decorator > screen by defining the location of communicationDecoratorLocation in > your app's web.xml file (just like mainDecoratorLocation). > > If that solves your problem, then create a patch and I will > review/commit it. > > -Adrian > > BJ Freeman wrote: > >> you missed something >> I can simply copy paste the Context into my web.xml since these are >> defined in each apps web.xml. >> >> I am pointing out that what ever is reading the controller in a >> application should also read the web.xml contexts. >> This would make it so there is no need to copy anything. >> >> Adrian Crum sent the following on 11/7/2007 2:19 PM: >> >>> It all depends on what you're trying to accomplish and how to tackle it. >>> >>> It appears from your emails that you're including the party manager >>> controller.xml file in a custom app. That is an easy way to gain access >>> to party manager screens within the custom app. But you'll run into >>> problems doing it that way. >>> >>> Another way to approach it is to set up the requests and view maps in >>> your custom app's controller.xml file that point to the screen >>> definitions in the party manager component. From my perspective, that >>> will give you more control. >>> >>> Either way, you'll have a problem with these "sub-decorator" screens. >>> How you handle that issue depends on what your trying to achieve. If you >>> want to use the same decorator screens, then you'll have to C&P them >>> into your custom app's CommonScreens.xml file. If you don't want to use >>> them, then just create empty decorator screens in your custom app's >>> CommonScreens.xml file. >>> >>> -Adrian >>> >>> BJ Freeman wrote: >>> >>> >>>> or if the web.xml context is allowed the lookup should include the >>>> web.xml for that component. >>>> >>>> >>>> >>>> Adrian Crum sent the following on 11/7/2007 1:57 PM: >>>> >>>> >>>>> I understand now, thank you for the clarification. >>>>> >>>>> You would have to create your own CommonCommunicationEventDecorator >>>>> decorator in your component's CommonScreens.xml file. >>>>> >>>>> At first glance, it appears the CommunicationScreens.xml file should >>>>> contain the CommonCommunicationEventDecorator screen. That would make >>>>> the screens easier to reuse. >>>>> >>>>> -Adrian >>>>> >>>>> 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 was suggesting that YOU create the patch - I don't have time to work on this right now.
-Adrian BJ Freeman wrote: > yes include the web.xml also > > > before you create a patch make sure it is best practices and it will be > folllowed > after all they were that way then the context directive started being used. > if no one is going to follow this practice you will be patching till you > know what freezes over. > > so right now you have all the application and those in the frame work to > patch. > > > > Adrian Crum sent the following on 11/7/2007 3:10 PM: > >>Are you saying this: >> >>if you include an external controller.xml file in your app's >>controller.xml file, then there should be a way to include the external >>web.xml in your app's web.xml file too? >> >>In this particular scenario, I think there is a better way to solve the >>problem: >> >>In the party manager component, move the >>CommonCommunicationEventDecorator screen definition into the >>CommunicationScreens.xml file, then change the lines that say >> >><decorator-screen name="CommonCommunicationEventDecorator" >>location="${parameters.mainDecoratorLocation}"> >> >>to >> >><decorator-screen name="CommonCommunicationEventDecorator" >>location="${parameters.communicationDecoratorLocation}"> >> >>That way you can reuse the communication screens as-is and they will >>default to the OOTB decorator screen, OR you can use your own decorator >>screen by defining the location of communicationDecoratorLocation in >>your app's web.xml file (just like mainDecoratorLocation). >> >>If that solves your problem, then create a patch and I will >>review/commit it. >> >>-Adrian >> >>BJ Freeman wrote: >> >> >>>you missed something >>>I can simply copy paste the Context into my web.xml since these are >>>defined in each apps web.xml. >>> >>>I am pointing out that what ever is reading the controller in a >>>application should also read the web.xml contexts. >>>This would make it so there is no need to copy anything. >>> >>>Adrian Crum sent the following on 11/7/2007 2:19 PM: >>> >>> >>>>It all depends on what you're trying to accomplish and how to tackle it. >>>> >>>>It appears from your emails that you're including the party manager >>>>controller.xml file in a custom app. That is an easy way to gain access >>>>to party manager screens within the custom app. But you'll run into >>>>problems doing it that way. >>>> >>>>Another way to approach it is to set up the requests and view maps in >>>>your custom app's controller.xml file that point to the screen >>>>definitions in the party manager component. From my perspective, that >>>>will give you more control. >>>> >>>>Either way, you'll have a problem with these "sub-decorator" screens. >>>>How you handle that issue depends on what your trying to achieve. If you >>>>want to use the same decorator screens, then you'll have to C&P them >>>>into your custom app's CommonScreens.xml file. If you don't want to use >>>>them, then just create empty decorator screens in your custom app's >>>>CommonScreens.xml file. >>>> >>>>-Adrian >>>> >>>>BJ Freeman wrote: >>>> >>>> >>>> >>>>>or if the web.xml context is allowed the lookup should include the >>>>>web.xml for that component. >>>>> >>>>> >>>>> >>>>>Adrian Crum sent the following on 11/7/2007 1:57 PM: >>>>> >>>>> >>>>> >>>>>>I understand now, thank you for the clarification. >>>>>> >>>>>>You would have to create your own CommonCommunicationEventDecorator >>>>>>decorator in your component's CommonScreens.xml file. >>>>>> >>>>>>At first glance, it appears the CommunicationScreens.xml file should >>>>>>contain the CommonCommunicationEventDecorator screen. That would make >>>>>>the screens easier to reuse. >>>>>> >>>>>>-Adrian >>>>>> >>>>>>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. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >> >> >> > |
|
|
ah. missed that part.
I think i will put my energy into getting the web.xml included :) Adrian Crum sent the following on 11/8/2007 7:58 AM: > I was suggesting that YOU create the patch - I don't have time to work > on this right now. > > -Adrian > > BJ Freeman wrote: >> yes include the web.xml also >> >> >> before you create a patch make sure it is best practices and it will be >> folllowed >> after all they were that way then the context directive started being >> used. >> if no one is going to follow this practice you will be patching till you >> know what freezes over. >> >> so right now you have all the application and those in the frame work to >> patch. >> >> >> >> Adrian Crum sent the following on 11/7/2007 3:10 PM: >> >>> Are you saying this: >>> >>> if you include an external controller.xml file in your app's >>> controller.xml file, then there should be a way to include the external >>> web.xml in your app's web.xml file too? >>> >>> In this particular scenario, I think there is a better way to solve the >>> problem: >>> >>> In the party manager component, move the >>> CommonCommunicationEventDecorator screen definition into the >>> CommunicationScreens.xml file, then change the lines that say >>> >>> <decorator-screen name="CommonCommunicationEventDecorator" >>> location="${parameters.mainDecoratorLocation}"> >>> >>> to >>> >>> <decorator-screen name="CommonCommunicationEventDecorator" >>> location="${parameters.communicationDecoratorLocation}"> >>> >>> That way you can reuse the communication screens as-is and they will >>> default to the OOTB decorator screen, OR you can use your own decorator >>> screen by defining the location of communicationDecoratorLocation in >>> your app's web.xml file (just like mainDecoratorLocation). >>> >>> If that solves your problem, then create a patch and I will >>> review/commit it. >>> >>> -Adrian >>> >>> BJ Freeman wrote: >>> >>> >>>> you missed something >>>> I can simply copy paste the Context into my web.xml since these are >>>> defined in each apps web.xml. >>>> >>>> I am pointing out that what ever is reading the controller in a >>>> application should also read the web.xml contexts. >>>> This would make it so there is no need to copy anything. >>>> >>>> Adrian Crum sent the following on 11/7/2007 2:19 PM: >>>> >>>> >>>>> It all depends on what you're trying to accomplish and how to >>>>> tackle it. >>>>> >>>>> It appears from your emails that you're including the party manager >>>>> controller.xml file in a custom app. That is an easy way to gain >>>>> access >>>>> to party manager screens within the custom app. But you'll run into >>>>> problems doing it that way. >>>>> >>>>> Another way to approach it is to set up the requests and view maps in >>>>> your custom app's controller.xml file that point to the screen >>>>> definitions in the party manager component. From my perspective, that >>>>> will give you more control. >>>>> >>>>> Either way, you'll have a problem with these "sub-decorator" screens. >>>>> How you handle that issue depends on what your trying to achieve. >>>>> If you >>>>> want to use the same decorator screens, then you'll have to C&P them >>>>> into your custom app's CommonScreens.xml file. If you don't want to >>>>> use >>>>> them, then just create empty decorator screens in your custom app's >>>>> CommonScreens.xml file. >>>>> >>>>> -Adrian >>>>> >>>>> BJ Freeman wrote: >>>>> >>>>> >>>>> >>>>>> or if the web.xml context is allowed the lookup should include the >>>>>> web.xml for that component. >>>>>> >>>>>> >>>>>> >>>>>> Adrian Crum sent the following on 11/7/2007 1:57 PM: >>>>>> >>>>>> >>>>>> >>>>>>> I understand now, thank you for the clarification. >>>>>>> >>>>>>> You would have to create your own CommonCommunicationEventDecorator >>>>>>> decorator in your component's CommonScreens.xml file. >>>>>>> >>>>>>> At first glance, it appears the CommunicationScreens.xml file should >>>>>>> contain the CommonCommunicationEventDecorator screen. That would >>>>>>> make >>>>>>> the screens easier to reuse. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> 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 hans_bakker
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. >>>> >>>> >>>> >>>> >>> >>> |
|
|
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 will not submit a patch for what I am proposing, like a lot of my
code, it stays in the applications I am doing. and since someone else put effort into what is in ofbiz now I do not plan to put effort into reversing it. :) Adrian Crum sent the following on 11/9/2007 4:57 PM: > BJ, > > As I mentioned before, I believe it would be better/easier to fix the > party manager screens. Including web.xml files will open up a big can of > worms. > > -Adrian > > BJ Freeman wrote: > >> Hans: >> I did not put the CommonCommunicationEventDecorator location in the >> context in web.xml >> this was done by someone else and is a standard through ofbiz as far as >> i can tell. >> I take the path of least resistance. >> Since it is possible to put context in the web.xml and someone has put a >> lot of effort into refactoring ofbiz to this standard, I have no >> intention of undoing it. >> >> so my focus for my code will be to have the web.xml included as well, >> unless the powers to be say there is going to be a change in the best >> practices. >> >> >> >> >> Hans Bakker sent the following on 11/7/2007 5:47 PM: >> >>> Hi Bj, >>> >>> request (or provide a patch) that the CommonCommunicationEventDecorator >>> is moved to the xml file as defined in the web.xml parameter. Also >>> request that the 'location' parameter is defined in the screen you are >>> using. >>> >>> Then you can use this screen in your own application using your own >>> decorator. >>> >>> Regards, >>> Hans >>> >>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote: >>> >>>> I have a controller.xml >>>> it has the include for the partymgr in it. >>>> I have a menu widget that calls the partmgr >>>> I have the PartymgrDecoratorLocation in my web.xml >>>> so I get to the find screen OK. >>>> I have a few others in my web.xml as well. >>>> so I can navigate. >>>> however if you don't have these in your web.xml that is in the same >>>> directory as the controller.xml you are using >>>> https://localhost:8443/myapp/control/partymgr >>>> then you get messages like this. >>>> >>>> org.ofbiz.base.util.GeneralException: Error rendering screen >>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]: >>>> >>>> java.lang.IllegalArgumentException: Could not find screen with name >>>> [CommonCommunicationEventDecorator] in the same file as the screen with >>>> name [EditCommunicationEvent] (Could not find screen with name >>>> [CommonCommunicationEventDecorator] in the same file as the screen with >>>> name [EditCommunicationEvent]) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> BJ, >>>> >>>> Do you have any specific examples of what you're describing? >>>> >>>> -Adrian >>>> >>>> >>>> BJ Freeman sent the following on 11/5/2007 3:59 PM: >>>> >>>>> sorry not a complete thougt >>>>> This is not a real bug. >>>>> when you included another contorller >>>>> and there is a commonscreen.xml defined in the web.xml of the calling >>>>> controller application it causes an error. >>>>> so maybe puttting the application name before commonescreens will >>>>> eliminate that. >>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM: >>>>> >>>>>> This is not a real bug. >>>>>> when you included another contorller >>>>>> and it has a commonscreen.xml >>>>>> >>>>>> another is that when the the other widget from the included >>>>>> controller >>>>>> calls for a context that is in the web.xml of that application. >>>>>> it is not found. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >> > > > > |
|
|
In reply to this post by Adrian Crum
BTW my current solution is a copy the web.xml context in to myapp web.xml
working except to main-decorator that a lot of the applications use and they are not the same. Adrian Crum sent the following on 11/9/2007 4:57 PM: > BJ, > > As I mentioned before, I believe it would be better/easier to fix the > party manager screens. Including web.xml files will open up a big can of > worms. > > -Adrian > > BJ Freeman wrote: > >> Hans: >> I did not put the CommonCommunicationEventDecorator location in the >> context in web.xml >> this was done by someone else and is a standard through ofbiz as far as >> i can tell. >> I take the path of least resistance. >> Since it is possible to put context in the web.xml and someone has put a >> lot of effort into refactoring ofbiz to this standard, I have no >> intention of undoing it. >> >> so my focus for my code will be to have the web.xml included as well, >> unless the powers to be say there is going to be a change in the best >> practices. >> >> >> >> >> Hans Bakker sent the following on 11/7/2007 5:47 PM: >> >>> Hi Bj, >>> >>> request (or provide a patch) that the CommonCommunicationEventDecorator >>> is moved to the xml file as defined in the web.xml parameter. Also >>> request that the 'location' parameter is defined in the screen you are >>> using. >>> >>> Then you can use this screen in your own application using your own >>> decorator. >>> >>> Regards, >>> Hans >>> >>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote: >>> >>>> I have a controller.xml >>>> it has the include for the partymgr in it. >>>> I have a menu widget that calls the partmgr >>>> I have the PartymgrDecoratorLocation in my web.xml >>>> so I get to the find screen OK. >>>> I have a few others in my web.xml as well. >>>> so I can navigate. >>>> however if you don't have these in your web.xml that is in the same >>>> directory as the controller.xml you are using >>>> https://localhost:8443/myapp/control/partymgr >>>> then you get messages like this. >>>> >>>> org.ofbiz.base.util.GeneralException: Error rendering screen >>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]: >>>> >>>> java.lang.IllegalArgumentException: Could not find screen with name >>>> [CommonCommunicationEventDecorator] in the same file as the screen with >>>> name [EditCommunicationEvent] (Could not find screen with name >>>> [CommonCommunicationEventDecorator] in the same file as the screen with >>>> name [EditCommunicationEvent]) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> BJ, >>>> >>>> Do you have any specific examples of what you're describing? >>>> >>>> -Adrian >>>> >>>> >>>> BJ Freeman sent the following on 11/5/2007 3:59 PM: >>>> >>>>> sorry not a complete thougt >>>>> This is not a real bug. >>>>> when you included another contorller >>>>> and there is a commonscreen.xml defined in the web.xml of the calling >>>>> controller application it causes an error. >>>>> so maybe puttting the application name before commonescreens will >>>>> eliminate that. >>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM: >>>>> >>>>>> This is not a real bug. >>>>>> when you included another contorller >>>>>> and it has a commonscreen.xml >>>>>> >>>>>> another is that when the the other widget from the included >>>>>> controller >>>>>> calls for a context that is in the web.xml of that application. >>>>>> it is not found. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >> > > > > |
|
|
In reply to this post by BJ Freeman
BJ,
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. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >> >> >> > |
|
|
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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>> >>> >>> >> > > > > |
|
|
Just want to make sure we are all on the same page
in a widget screen <decorator-screen name="CommonPartyDecorator" location="${parameters.mainDecoratorLocation}"> parameters.mainDecoratorLocation is in the Web.xml <context-param> <param-name>mainDecoratorLocation</param-name> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value> <description>The location of the main-decorator screen to use for this webapp; referred to as a context variable in screen def XML files.</description> </context-param> so to "fix" <decorator-screen name="CommonPartyDecorator" location="component://party/widget/partymgr/CommonScreens.xml"> BJ Freeman sent the following on 11/9/2007 5:17 PM: > Ok so the code that allows the context to be used in the web.xml is > being depreciated? > > > Adrian Crum sent the following on 11/9/2007 5:11 PM: >> BJ, >> >> Nothing is being reversed. You have pointed out a weakness in how the >> some of the party manager screens are set up (they can't be reused). I >> have confirmed they have a problem. So submitting a patch FIXES the >> issue - it doesn't reverse anything. >> >> -Adrian >> >> BJ Freeman wrote: >> >>> I will not submit a patch for what I am proposing, like a lot of my >>> code, it stays in the applications I am doing. >>> and since someone else put effort into what is in ofbiz now >>> I do not plan to put effort into reversing it. >>> :) >>> >>> Adrian Crum sent the following on 11/9/2007 4:57 PM: >>> >>>> BJ, >>>> >>>> As I mentioned before, I believe it would be better/easier to fix the >>>> party manager screens. Including web.xml files will open up a big can of >>>> worms. >>>> >>>> -Adrian >>>> >>>> BJ Freeman wrote: >>>> >>>> >>>>> Hans: >>>>> I did not put the CommonCommunicationEventDecorator location in the >>>>> context in web.xml >>>>> this was done by someone else and is a standard through ofbiz as far as >>>>> i can tell. >>>>> I take the path of least resistance. >>>>> Since it is possible to put context in the web.xml and someone has >>>>> put a >>>>> lot of effort into refactoring ofbiz to this standard, I have no >>>>> intention of undoing it. >>>>> >>>>> so my focus for my code will be to have the web.xml included as well, >>>>> unless the powers to be say there is going to be a change in the best >>>>> practices. >>>>> >>>>> >>>>> >>>>> >>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM: >>>>> >>>>> >>>>>> Hi Bj, >>>>>> >>>>>> request (or provide a patch) that the >>>>>> CommonCommunicationEventDecorator >>>>>> is moved to the xml file as defined in the web.xml parameter. Also >>>>>> request that the 'location' parameter is defined in the screen you are >>>>>> using. >>>>>> >>>>>> Then you can use this screen in your own application using your own >>>>>> decorator. >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote: >>>>>> >>>>>> >>>>>>> I have a controller.xml >>>>>>> it has the include for the partymgr in it. >>>>>>> I have a menu widget that calls the partmgr >>>>>>> I have the PartymgrDecoratorLocation in my web.xml >>>>>>> so I get to the find screen OK. >>>>>>> I have a few others in my web.xml as well. >>>>>>> so I can navigate. >>>>>>> however if you don't have these in your web.xml that is in the same >>>>>>> directory as the controller.xml you are using >>>>>>> https://localhost:8443/myapp/control/partymgr >>>>>>> then you get messages like this. >>>>>>> >>>>>>> org.ofbiz.base.util.GeneralException: Error rendering screen >>>>>>> [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]: >>>>>>> >>>>>>> >>>>>>> java.lang.IllegalArgumentException: Could not find screen with name >>>>>>> [CommonCommunicationEventDecorator] in the same file as the screen >>>>>>> with >>>>>>> name [EditCommunicationEvent] (Could not find screen with name >>>>>>> [CommonCommunicationEventDecorator] in the same file as the screen >>>>>>> with >>>>>>> name [EditCommunicationEvent]) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> BJ, >>>>>>> >>>>>>> Do you have any specific examples of what you're describing? >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> BJ Freeman sent the following on 11/5/2007 3:59 PM: >>>>>>> >>>>>>> >>>>>>>> sorry not a complete thougt >>>>>>>> This is not a real bug. >>>>>>>> when you included another contorller >>>>>>>> and there is a commonscreen.xml defined in the web.xml of the >>>>>>>> calling >>>>>>>> controller application it causes an error. >>>>>>>> so maybe puttting the application name before commonescreens will >>>>>>>> eliminate that. >>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55 PM: >>>>>>>> >>>>>>>> >>>>>>>>> This is not a real bug. >>>>>>>>> when you included another contorller >>>>>>>>> and it has a commonscreen.xml >>>>>>>>> >>>>>>>>> another is that when the the other widget from the included >>>>>>>>> controller >>>>>>>>> calls for a context that is in the web.xml of that application. >>>>>>>>> it is not found. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>> >> >> >> > > > |
|
|
In reply to this post by BJ Freeman
I 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 >>>> 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. >>>>>> 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 >>>>>>> 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 >>>>>>>> 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 >>>>>>>>> it is not found. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>> >>>> >> >> >> > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |