I don't agree that that is the only way to solve the problem. I have suggested the CORRECT solution
to this problem ever since the beginning of this thread, but that solution is being ignored, and
instead it is being replced with a kludge that tries to fix a SYMPTOM, and not the real problem.
-Adrian
Chris Howe wrote:
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.
