Re: mainDecoratorLocation was Include of controllers

[Adrian Crum]

The best way to prove it is to code it according to my suggestion and test it against the original 
problem you stated in this thread. It works. How do I know that? Because I did it a month ago.

-Adrian
BJ Freeman wrote:

best way to prove this is to have a menu in a new app.
point it to two different screens one in each app.
try to get both screens to work with out error.
even using your code.

BJ Freeman sent the following on 12/17/2007 1:39 PM:

you did not say to change
<decorator-screen name="main-decorator"
location="${parameters.mainDecoratorLocation}">

so even your change will not work.

Adrian Crum sent the following on 12/17/2007 1:32 PM:

That line wouldn't exist if you made the change I suggested.

Make the code changes, THEN tell me what's wrong with it. Telling me
what's already wrong with it is pointless - I already know the existing
code doesn't work.


BJ Freeman wrote:


I beg to differ with you.
where is
               <decorator-screen
name="CommonCommunicationEventDecorator"
location="${parameters.mainDecoratorLocation}">

defined
where is
               <decorator-screen name="main-decorator"
location="${parameters.mainDecoratorLocation}">
in the CommonPartyDecorator defined.

Adrian Crum sent the following on 12/17/2007 1:03 PM:


ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.



The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
contain anything specific to the Party Manager's web.xml file. I don't
see what the problem is.

Maybe you should include an exact error message.

-Adrian

BJ Freeman wrote:



I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.

so lets say i put in a mainDecoratorLocation in my web xml and
define it
like the one in the party commonscreens.xml

so far so good.

Now I call a screen in say Product. except the mainDecoratorLocation
for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.

we still have a problem since all the apps main-decorators are not the
same.

now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok



Adrian Crum sent the following on 12/17/2007 12:40 PM:



1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
<decorator-screen name="CommonCommunicationEventDecorator"
location="${parameters.mainDecoratorLocation}">

to

<decorator-screen name="CommonCommunicationEventDecorator"
location="${parameters.communicationEventDecoratorLocation}">

Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
same
in Party Manager, but now you can reuse those screens in another app.

When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
your
custom app's main decorator.

(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.

-Adrian

BJ Freeman wrote:




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.