I will still get the error since the parameters.mainDecoratorLocation
for that is in the web.xml for party.
BJ Freeman sent the following on 12/17/2007 12:23 PM:
> Ok here is a real situation:
> take the party/widgets/partymgr/commicationsscreens.xml
> <decorator-screen name="CommonCommunicationEventDecorator"
> location="${parameters.mainDecoratorLocation}">
> which is the CommonSreens.xml
> which has
> <decorator-screen name="main-decorator"
> location="${parameters.mainDecoratorLocation}">
>
> the main-decorator has
> <include-screen name="GlobalDecorator"
> location="component://common/widget/CommonScreens.xml"/>
>
>
> how would the be with your example
>
>
>
> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>> BJ,
>>
>> Go ahead and create one. I will work on it when I have time.
>>
>> To be sure we're all on the same page, the problem exists when screens
>> are nested as follows:
>>
>> <screen name="GlobalDecorator">
>> <screen name="main-decorator">
>> <screen name="sub-decorator">
>> <screen name="actual-content">
>> ...
>> </screen>
>> </screen>
>> </screen>
>> </screen>
>>
>> and the location of the sub-decorator screen is defined as
>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>> the actual-content screen, errors are generated because
>> <decorator-screen name="sub-decorator"
>> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
>> app's main decorator xml file, and the sub-decorator screen doesn't
>> exist there.
>>
>> The solution to the problem is to avoid using
>> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
>> either have no location specified or use a different parameter for the
>> sub-decorator's location - like ${subDecoratorLocation}.
>>
>> A good example of this approach is in AgreementScreens.xml in the
>> Accounting component. All of the Agreement screens share a common
>> sub-decorator (CommonAgreementDecorator) - and that decorator's location
>> is specified as ${parameters.agreementDecoratorLocation}. The
>> agreementDecoratorLocation parameter isn't defined anywhere, so the
>> location= expression evaluates to an empty String - which causes the
>> screen widget view handler to look for CommonAgreementDecorator in the
>> existing file.
>>
>> A custom app that reuses one of the Agreement screens will only need to
>> specify the mainDecoratorLocation parameter. Since no
>> agreementDecoratorLocation parameter is defined in the custom app, the
>> sub-decorator in AgreementScreens.xml is used (same as above). If a
>> custom app wanted to have a custom sub-decorator, then it can specify
>> that decorator's location in the agreementDecoratorLocation parameter.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>> I agree, it is not a controller or web.xml issue. However it is when it
>>> shows up.
>>> I will change them as I come along also.
>>> thanks, that is all I wanted to know.
>>> do you want to create a jira so I can submit changes?
>>>
>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>
>>>> As I mentioned before, the problem is with the coding style on some
>>>> screens, not with the controller or web.xml files. I recently changed
>>>> some of the accounting screens to correct this error.
>>>>
>>>> -Adrian
>>>>
>>>> BJ Freeman wrote:
>>>>
>>>>
>>>>> I am not really, trying to attach the context as a whole.
>>>>> only trying to get the mainDecoratorLocation
>>>>> which is stored as a context in web.xml.
>>>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>>>> then all applications I call thru my controller, or the included ones,
>>>>> will use my mainDecoratorLocation full path.
>>>>> Maybe the solution is to put the main-decorator for all apps in the
>>>>> framework/commons
>>>>> then like in many of the application they have specific decorators that
>>>>> include the main-decorator.
>>>>> the problems is how to fill in the actions, etcetera
>>>>>
>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>
>>>>>
>>>>>> All the <include> does is grab some xml elements from the location
>>>>>> described. Theoretically, It doesn't even need to be from the same
>>>>>> server, much less the same app (may have interesting possibilities
>>>>>> BTW). This is why I'm having such a hard time understanding why you
>>>>>> are trying to attach context to it.
>>>>>>
>>>>>> ----- Original Message ----
>>>>>> From: BJ Freeman <[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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>
