BJ's problem occurs because when he <include>s the party
controller and the catalog controller, he wants the requests/views from
the party controller to have mainDecoratorLocation equal one place and
the requests/views from the catalog controller to equal another.
The only way for it to solve BJ's issue is to replace current
${parameters.mainDecoratorLocation} with
${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation}
or to remove the variable location altogether, thus breaking the ability call
that screen from a custom application. Not simply provide a variable to
<decororator-screen> location's that are empty.
----- Original Message ----
From: Adrian Crum <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, December 17, 2007 11:46:26 AM
Subject: Re: Include of controllers
If BJ supplies a patch as I described, then we'll see if it solves his
problem. If it does, then
we're talking about the same issue. ;-)
-Adrian
Chris Howe wrote:
> You two are talking about different issues. BJ is describing a
pitfall that occurs when you use the <include> tag in the controller for a
scenario that wasn't considered when the <include> tag was implemented
in the controller.
>
> ----- Original Message ----
> From: Adrian Crum <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Monday, December 17, 2007 11:33:43 AM
> Subject: Re: Include of controllers
>
>
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when
screens
> are nested as follows:
>
> <screen name="GlobalDecorator">
> <screen name="main-decorator">
> <screen name="sub-decorator">
> <screen name="actual-content">
> ...
> </screen>
> </screen>
> </screen>
> </screen>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When
> a custom app tries to reuse the actual-content screen, errors are
> generated because
> <decorator-screen name="sub-decorator"
> location="${parameters.mainDecoratorLocation}"> evaluates to
> the custom app's main decorator xml file, and the sub-decorator
screen
> doesn't exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for
> sub-decorators and either have no location specified or use a
different
> parameter for the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the
> Agreement screens share a common sub-decorator
> (CommonAgreementDecorator) - and that decorator's
> location is specified as ${parameters.agreementDecoratorLocation}.
The
> agreementDecoratorLocation
> parameter isn't defined anywhere, so the location= expression
evaluates
> to an empty String - which
> causes the screen widget view handler to look for
> CommonAgreementDecorator in the existing file.
>
> A custom app that reuses one of the Agreement screens will only need
to
> specify the
> mainDecoratorLocation parameter. Since no agreementDecoratorLocation
> parameter is defined in the
> custom app, the sub-decorator in AgreementScreens.xml is used (same
as
> above). If a custom app
> wanted to have a custom sub-decorator, then it can specify that
> decorator's location in the
> agreementDecoratorLocation parameter.
>
> -Adrian
>
> BJ Freeman wrote:
>
>
>>I agree, it is not a controller or web.xml issue. However it is when
>
> it
>
>>shows up.
>>I will change them as I come along also.
>>thanks, that is all I wanted to know.
>>do you want to create a jira so I can submit changes?
>>
>>Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>
>>
>>>As I mentioned before, the problem is with the coding style on some
>>>screens, not with the controller or web.xml files. I recently
changed
>>>some of the accounting screens to correct this error.
>>>
>>>-Adrian
>>>
>>>BJ Freeman wrote:
>>>
>>>
>>>
>>>>I am not really, trying to attach the context as a whole.
>>>>only trying to get the mainDecoratorLocation
>>>>which is stored as a context in web.xml.
>>>>The problem is if I put mainDecoratorLocation, in my web.xml
>>>>then all applications I call thru my controller, or the included
>
> ones,
>
>>>>will use my mainDecoratorLocation full path.
>>>>Maybe the solution is to put the main-decorator for all apps in the
>>>>framework/commons
>>>>then like in many of the application they have specific decorators
>
> that
>
>>>>include the main-decorator.
>>>>the problems is how to fill in the actions, etcetera
>>>>
>>>>Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>
>>>>
>>>>
>>>>>All the <include> does is grab some xml elements from the location
>>>>>described. Theoretically, It doesn't even need to be from the
same
>>>>>server, much less the same app (may have interesting possibilities
>>>>>BTW). This is why I'm having such a hard time understanding why
>
> you
>
>>>>>are trying to attach context to it.
>>>>>
>>>>>----- Original Message ----
>>>>>From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>To: [email protected]
>>>>>Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>Subject: Re: Include of controllers
>>>>>
>>>>>
>>>>>I was going thru the trunk and noticed this in all the controllers
>>>>> <include
>>>>>location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>>>>
>>>>>so there is a rule that says you can include a controller not in
>
> the
>
>>>>>same app.
>>>>>
>>>>>
>>>>>BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>
>>>>>
>>>>>
>>>>>>Almost.
>>>>>>when the included controller view calles a screen in the partymgr
>>>>>
>>>>>screen
>>>>>
>>>>>
>>>>>
>>>>>>, and that screen calls for a parm that is web.xml. the parm is
>
> not
>
>>>>>>availible for the screen and so fails.
>>>>>>
>>>>>>At this time, the way I handle this is to put the parm in my
>
> Web.xml.
>
>>>>>>My suggestions was that if a call is made to a parm that would be
>
> in
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>applications, in this case partymgr, web.xml, that widget looks
up
>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>web.xml for that application to get it.
>>>>>>
>>>>>>
>>>>>>Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Okay, I've read through the thread. In that case, I might
>
> suggest
>
>>>>>to take a step back and look at what the two functionalities were
>>>>>designed to accomplish.
>>>>>
>>>>>
>>>>>>>Creating the mainDecoratorLocation variable in the web.xml was
>>>>>
>>>>>designed for _screen reuse. the include element in the
>
> controller.xml
>
>>>>>file
>>>>>was designed for request/response maintenance.
>>>>>
>>>>>
>>>>>>>With that in mind, you can include another controller in your
>
> custom
>
>>>>>application and then override the view with one that points to
your
>>>>>application. If you wish to then include a screen from another
>>>>>application you can use the <include-screen> element in the screen
>>>>>widget and
>>>>>at the same time pass a parameters.mainDecoratorLocation to
>
> override the
>
>>>>>one gained from the web.xml context of the webapp being used.
>>>>>
>>>>>
>>>>>
>>>>>>>It appears that what BJ is suggesting would make the screen
being
>>>>>
>>>>>called from the ofbiz application nonreusable except as decorated
>
> as it
>
>>>>>is in the ofbiz project which defeats the entire purpose of the
>>>>>mainDecoratorLocation variable. Do I follow correctly?
>>>>>
>>>>>
>>>>>
>>>>>>>----- Original Message ----
>>>>>>>From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>To: [email protected]
>>>>>>>Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>>Subject: Re: Include of controllers
>>>>>>>
>>>>>>>Chris the discussion is about using the include in the
>
> controller.
>
>>>>>>>and that the current way of putting the locations of parameters
>
> used
>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>the widgets for screen decorators is causing a problem
>>>>>>>In a lot of apps the location is called out in the web.xml
>>>>>>><context-param>
>>>>>>><param-name>mainDecoratorLocation</param-name>
>>>>>>>
>>>>><param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>>>
>>>>>
>>>>>>> <description>The location of the main-decorator screen to use
>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>this webapp; referred to as a context variable in screen def XML
>>>>>>>files.</description>
>>>>>>> </context-param>
>>>>>>>
>>>>>>>The suggeston is to take the location out to the web.xml and put
>
> in
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>widget like so.
>>>>>>>
>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I haven't been following the thread, but instead of setting it
>>>>>>>
>>>>>>>explicitly in the widgets section, you may prefer to define it
in
>>>>>
>>>>>the actions
>>>>>
>>>>>
>>>>>
>>>>>>>section...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>><action>
>>>>>>>> <set field="parameters.mainDecoratorLocation"
>>>>>>>
>>>>>>>value="component://party/widget/partymgr/CommonScreens.xml"/>
>>>>>>>
>>>>>>>></action>
>>>>>>>><widget>
>>>>>>>> <include-screen name="splitScreen"/>
>>>>>>>></widget>
>>>>>>>>...
>>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>
>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>
>>>>>>>><screen name="splitScreen">
>>>>>>>>...
>>>>>>>><widget>
>>>>>>>>
>>>>>>>></widget>
>>>>>>>>...
>>>>>>>>or something similar that it remains a variable so that you can
>>>>>
>>>>>later
>>>>>
>>>>>
>>>>>
>>>>>>>split the widget section out to be it's own screen so that it
can
>>>>>
>>>>>be
>>>>>
>>>>>
>>>>>
>>>>>>>used with the decorator in another webapp. I don't know if the
>>>>>
>>>>>screens
>>>>>
>>>>>
>>>>>
>>>>>>>you're worried about here are that complex. This has been a
>>>>>
>>>>>better
>>>>>
>>>>>
>>>>>
>>>>>>>pattern for me.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>----- Original Message ----
>>>>>>>>From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>>To: [email protected]
>>>>>>>>Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>
>>>>>>>>Just want to make sure we are all on the same page
>>>>>>>>in a widget screen
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>>
>>>>>>>>parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>
>>>>>>>><context-param>
>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>
>
<param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>
>>>>>
>>>>>>>> <description>The location of the main-decorator screen to use
>>>>>
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>>this webapp; referred to as a context variable in screen def
XML
>>>>>>>>files.</description>
>>>>>>>></context-param>
>>>>>>>>
>>>>>>>>so to "fix"
>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>location="component://party/widget/partymgr/CommonScreens.xml">
>>>>>>>>
>>>>>>>>
>>>>>>>>BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Ok so the code that allows the context to be used in the
>
> web.xml
>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>>>>being depreciated?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>BJ,
>>>>>>>>>>
>>>>>>>>>>Nothing is being reversed. You have pointed out a weakness in
>
> how
>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>some of the party manager screens are set up (they can't be
>>>>>>>
>>>>>>>reused).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>have confirmed they have a problem. So submitting a patch
>
> FIXES
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>issue - it doesn't reverse anything.
>>>>>>>>>>
>>>>>>>>>>-Adrian
>>>>>>>>>>
>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>I will not submit a patch for what I am proposing, like a
lot
>
> of
>
>>>>>>>my
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>code, it stays in the applications I am doing.
>>>>>>>>>>>and since someone else put effort into what is in ofbiz now
>>>>>>>>>>>I do not plan to put effort into reversing it.
>>>>>>>>>>>:)
>>>>>>>>>>>
>>>>>>>>>>>Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>BJ,
>>>>>>>>>>>>
>>>>>>>>>>>>As I mentioned before, I believe it would be better/easier
>
> to
>
>>>>>fix
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>party manager screens. Including web.xml files will open up
>
> a
>
>>>>>big
>>>>>
>>>>>
>>>>>
>>>>>>>>can of
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>worms.
>>>>>>>>>>>>
>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>
>>>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Hans:
>>>>>>>>>>>>>I did not put the CommonCommunicationEventDecorator
>
> location
>
>>>>>in
>>>>>
>>>>>
>>>>>
>>>>>>>>the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>context in web.xml
>>>>>>>>>>>>>this was done by someone else and is a standard through
>
> ofbiz
>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>far as
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>i can tell.
>>>>>>>>>>>>>I take the path of least resistance.
>>>>>>>>>>>>>Since it is possible to put context in the web.xml and
>
> someone
>
>>>>>>>>has
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>put a
>>>>>>>>>>>>>lot of effort into refactoring ofbiz to this standard, I
>
> have
>
>>>>>no
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>intention of undoing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>so my focus for my code will be to have the web.xml
>
> included
>
>>>>>as
>>>>>
>>>>>
>>>>>
>>>>>>>>well,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>unless the powers to be say there is going to be a change
>
> in
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>best
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>practices.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>Hi Bj,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>request (or provide a patch) that the
>>>>>>>>>>>>>>CommonCommunicationEventDecorator
>>>>>>>>>>>>>>is moved to the xml file as defined in the web.xml
>
> parameter.
>
>>>>>>>>Also
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>request that the 'location' parameter is defined in the
>>>>>
>>>>>screen
>>>>>
>>>>>
>>>>>
>>>>>>>>you are
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>using.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Then you can use this screen in your own application
using
>>>>>
>>>>>your
>>>>>
>>>>>
>>>>>
>>>>>>>>own
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>decorator.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Regards,
>>>>>>>>>>>>>>Hans
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>I have a controller.xml
>>>>>>>>>>>>>>>it has the include for the partymgr in it.
>>>>>>>>>>>>>>>I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>>I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>>so I get to the find screen OK.
>>>>>>>>>>>>>>>I have a few others in my web.xml as well.
>>>>>>>>>>>>>>>so I can navigate.
>>>>>>>>>>>>>>>however if you don't have these in your web.xml that is
>
> in
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>same
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>directory as the controller.xml you are using
>>>>>>>>>>>>>>>https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>>then you get messages like this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>org.ofbiz.base.util.GeneralException: Error rendering
>
> screen
>
>>>>>>>
>>>>>[component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>>java.lang.IllegalArgumentException: Could not find
screen
>>>>>
>>>>>with
>>>>>
>>>>>
>>>>>
>>>>>>>>name
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same file as
>
> the
>
>>>>>>>>screen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>name [EditCommunicationEvent] (Could not find screen
with
>>>>>
>>>>>name
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same file as
>
> the
>
>>>>>>>>screen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>name [EditCommunicationEvent])
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Do you have any specific examples of what you're
>
> describing?
>
>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:59 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>sorry not a complete thougt
>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>and there is a commonscreen.xml defined in the web.xml
>
> of
>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>>>calling
>>>>>>>>>>>>>>>>controller application it causes an error.
>>>>>>>>>>>>>>>>so maybe puttting the application name before
>>>>>
>>>>>commonescreens
>>>>>
>>>>>
>>>>>
>>>>>>>>will
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>eliminate that.
>>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:55 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>>and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>another is that when the the other widget from the
>>>>>
>>>>>included
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>>>>>>>controller
>>>>>>>>>>>>>>>>>calls for a context that is in the web.xml of that
>>>>>>>>
>>>>>>>>application.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>it is not found.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
>
>
>
