I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?

Adrian Crum sent the following on 12/17/2007 7:57 AM:
> As I mentioned before, the problem is with the coding style on some
> screens, not with the controller or web.xml files. I recently changed
> some of the accounting screens to correct this error.
> 
> -Adrian
> 
> BJ Freeman wrote:
> 
>> I am not really, trying to attach the context as a whole.
>> only trying to get the mainDecoratorLocation
>> which is stored as a context in web.xml.
>> The problem is if I put mainDecoratorLocation, in my web.xml
>> then all applications I call thru my controller, or the included ones,
>> will use my mainDecoratorLocation full path.
>> Maybe the solution is to put the main-decorator for all apps in the
>> framework/commons
>> then like in many of the application they have specific decorators that
>> include the main-decorator.
>> the problems is how to fill in the actions, etcetera
>>
>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>
>>> All the <include> does is grab some xml elements from the location
>>> described.  Theoretically, It doesn't even need to be from the same
>>> server, much less the same app (may have interesting possibilities
>>> BTW).  This is why I'm having such a hard time understanding why you
>>> are trying to attach context to it.
>>>
>>> ----- Original Message ----
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Saturday, December 15, 2007 12:19:27 PM
>>> Subject: Re: Include of controllers
>>>
>>>
>>> I was going thru the trunk and noticed this in all the controllers
>>>    <include
>>> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>
>>> so there is a rule that says you can include a controller not in the
>>> same app.
>>>
>>>
>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>
>>>> Almost.
>>>> when the included controller view calles a screen in the partymgr
>>>
>>> screen
>>>
>>>> , and that screen calls for a parm that is web.xml. the parm is not
>>>> availible for the screen and so fails.
>>>>
>>>> At this time, the way I handle this is to put the parm in my Web.xml.
>>>>
>>>> My suggestions was that if a call is made to a parm that would be in
>>>
>>> the
>>>
>>>> applications, in this case partymgr, web.xml, that widget looks up
>>>
>>> the
>>>
>>>> web.xml for that application to get it.
>>>>
>>>>
>>>> Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>
>>>>> Okay, I've read through the thread.  In that case, I might suggest
>>>
>>> to take a step back and look at what the two functionalities were
>>> designed to accomplish. 
>>>>> Creating the mainDecoratorLocation variable in the web.xml was
>>>
>>> designed for _screen reuse. the include element in the controller.xml
>>> file
>>> was designed for request/response maintenance. 
>>>>> With that in mind, you can include another controller in your custom
>>>
>>> application and then override the view with one that points to your
>>> application.   If you wish to then include a screen from another
>>> application you can use the <include-screen> element in the screen
>>> widget and
>>> at the same time pass a parameters.mainDecoratorLocation to override the
>>> one gained from the web.xml context of the webapp being used.
>>>
>>>>> It appears that what BJ is suggesting would make the screen being
>>>
>>> called from the ofbiz application nonreusable except as decorated as it
>>> is in the ofbiz project which defeats the entire purpose of the
>>> mainDecoratorLocation variable.  Do I follow correctly?
>>>
>>>>> ----- Original Message ----
>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>> To: dev@ofbiz.apache.org
>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>> Subject: Re: Include of controllers
>>>>>
>>>>> Chris the discussion is about using the include in the controller.
>>>>> and that the current way of putting the locations of parameters used
>>>
>>> in
>>>
>>>>> the widgets for screen decorators is causing a problem
>>>>> In a lot of apps the location is called out in the web.xml
>>>>>  <context-param>
>>>>>  <param-name>mainDecoratorLocation</param-name>
>>>>>
>>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>
>>>
>>>>>     <description>The location of the main-decorator screen to use
>>>
>>> for
>>>
>>>>> this webapp; referred to as a context variable in screen def XML
>>>>> files.</description>
>>>>>   </context-param>
>>>>>
>>>>> The suggeston is to take the location out to the web.xml and put in
>>>
>>> the
>>>
>>>>> widget like so.
>>>>>
>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>
>>>>>
>>>>>
>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>
>>>>>> I haven't been following the thread, but instead of setting it
>>>>>
>>>>> explicitly in the widgets section, you may prefer to define it in
>>>
>>> the actions
>>>
>>>>> section...
>>>>>
>>>>>> <action>
>>>>>>   <set field="parameters.mainDecoratorLocation"
>>>>>
>>>>> value="component://party/widget/partymgr/CommonScreens.xml"/>
>>>>>
>>>>>> </action>
>>>>>> <widget>
>>>>>>   <include-screen name="splitScreen"/>
>>>>>> </widget>
>>>>>> ...
>>>>>>  <decorator-screen name="CommonPartyDecorator"
>>>>>
>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>
>>>>>> <screen name="splitScreen">
>>>>>> ...
>>>>>> <widget>
>>>>>>  
>>>>>> </widget>
>>>>>> ...
>>>>>> or something similar that it remains a variable so that you can
>>>
>>> later
>>>
>>>>> split the widget section out to be it's own screen so that it can
>>>
>>> be
>>>
>>>>> used with the decorator in another webapp.  I don't know if the
>>>
>>> screens
>>>
>>>>> you're worried  about here are that complex.  This has been a
>>>
>>> better
>>>
>>>>> pattern for me.
>>>>>
>>>>>> ----- Original Message ----
>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>> To: dev@ofbiz.apache.org
>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>> Subject: Re: Include of controllers
>>>>>>
>>>>>> Just want to make sure we are all on the same page
>>>>>> in a widget screen
>>>>>>                <decorator-screen name="CommonPartyDecorator"
>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>
>>>>>> parameters.mainDecoratorLocation is in the Web.xml
>>>>>>
>>>>>> <context-param>
>>>>>>    <param-name>mainDecoratorLocation</param-name>
>>>>>>
>>>  
>>> <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>
>>>
>>>>>>    <description>The location of the main-decorator screen to use
>>>
>>> for
>>>
>>>>>> this webapp; referred to as a context variable in screen def XML
>>>>>> files.</description>
>>>>>>  </context-param>
>>>>>>
>>>>>> so to "fix"
>>>>>>                <decorator-screen name="CommonPartyDecorator"
>>>>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>
>>>>>>
>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>
>>>>>>> Ok so the code that allows the context to be used in the web.xml
>>>
>>> is
>>>
>>>>>>> being depreciated?
>>>>>>>
>>>>>>>
>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>
>>>>>>>> BJ,
>>>>>>>>
>>>>>>>> Nothing is being reversed. You have pointed out a weakness in how
>>>>>>
>>>>>> the
>>>>>>
>>>>>>>> some of the party manager screens are set up (they can't be
>>>>>
>>>>> reused).
>>>>>
>>>>>> I
>>>>>>
>>>>>>>> have confirmed they have a problem. So submitting a patch FIXES
>>>
>>> the
>>>
>>>>>>>> issue - it doesn't reverse anything.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> BJ Freeman wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> I will not submit a patch for what I am proposing, like a lot of
>>>>>
>>>>> my
>>>>>
>>>>>>>>> code, it stays in the applications I am doing.
>>>>>>>>> and since someone else put effort into what is in ofbiz now
>>>>>>>>> I do not plan to put effort into reversing it.
>>>>>>>>> :)
>>>>>>>>>
>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> BJ,
>>>>>>>>>>
>>>>>>>>>> As I mentioned before, I believe it would be better/easier to
>>>
>>> fix
>>>
>>>>>> the
>>>>>>
>>>>>>>>>> party manager screens. Including web.xml files will open up a
>>>
>>> big
>>>
>>>>>> can of
>>>>>>
>>>>>>>>>> worms.
>>>>>>>>>>
>>>>>>>>>> -Adrian
>>>>>>>>>>
>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hans:
>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator location
>>>
>>> in
>>>
>>>>>> the
>>>>>>
>>>>>>>>>>> context in web.xml
>>>>>>>>>>> this was done by someone else and is a standard through ofbiz
>>>
>>> as
>>>
>>>>>> far as
>>>>>>
>>>>>>>>>>> i can tell.
>>>>>>>>>>> I take the path of least resistance.
>>>>>>>>>>> Since it is possible to put context in the web.xml and someone
>>>>>>
>>>>>> has
>>>>>>
>>>>>>>>>>> put a
>>>>>>>>>>> lot of effort into refactoring ofbiz to this standard, I have
>>>
>>> no
>>>
>>>>>>>>>>> intention of undoing it.
>>>>>>>>>>>
>>>>>>>>>>> so my focus for my code will be to have the web.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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 

Reply via email to