That's probably where the disconnect is coming in. The way the system is set up, you would have your
own application menu, which would look something like:
My Custom Application
Main | My Page 1 | My Page 2 | Party Communications | Product Lookup | Logout
The Party Communcations screen would come from the Party Manager, and the Product Lookup screen
would come from Product Manager.
-Adrian
BJ Freeman wrote:
here is an exmple
<set field="applicationMenuName" value="SetupMainMenu" global="true"/>
<set field="applicationMenuLocation"
Value="component://setup/widget/setup/MainSetupMenus.xml" global="true"/>
now I can only setup that up for one menu
so how do I set that up for each menu for each app?
BJ Freeman sent the following on 12/17/2007 3:59 PM:
Oh.. well I did.
and got all sorts of errors because I has not included what that
application expected for its decorator.
and I could not find a way to use the app specific information for each
app in my main-decorator.
which started me down the road to app-mainDecoratorLocation
Chris Howe sent the following on 12/17/2007 3:50 PM:
Woops...pressed the send button by mistake.
Make your own decorator in /myapp/widget/CommonScreens.xml
create a main-decorator and a global decorator and use modify to your heart's
content
----- Original Message ----
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:33:01 PM
Subject: Re: mainDecoratorLocation was Include of controllers
so what is the approach that works?
Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
problem. The approach others have been using for the last two years does
not. I thought you were asserting that both approaches fail.
----- Original Message ----
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally declared
to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside that
app
Chris Howe sent the following on 12/17/2007 3:11 PM:
I'm not sure I understand what you mean by access multiple apps from
a custom app. When you have a custom app, there is no notion that
included screens, called screens, included controllers, etc have a
context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two or
five, it
doesn't matter. It only matters if you attempt to assert a context
of
ownership; that calling a controller from the party controller has
some
meaning about associated party variables or contexts.
----- Original Message ----
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 4:57:18 PM
Subject: Re: mainDecoratorLocation was Include of controllers
good point. #1
so I will not put this to sleep and do it for my releases until, as
you
say it become a problem
However the use of mainDecoratorLocation beyond an app should be
discourage for access multiple apps from a custom app as well.
the conflict of data in each main-decorator has specific app
information.
Chris Howe sent the following on 12/17/2007 2:47 PM:
Note: I'm not saying that prefixing the variable is a bad solution
I'm just throwing out the downsides of it
1) The use case you present should not be encouraged. The
opportunity for conflicting requests/views between multiple
controllers will
drive you bat crazy with unexpected results. The intent of the
<include>
element is to modularize commonly used requests/views. Throwing
everything in a bag and hoping you pull the expected result/view
out
is kind
of dangerous. Absent a compelling use case, movement towards an
external widely adopted standard, or utilizing more generic
practices it's
difficult to overcome the backward compatibility issue.
2) if you were to address the backward compatibility issue by
making
the mainDecoratorLocation the default if
[prefix]-mainDeocratorLocation
were null, I believe that you would be moving away from the Java
Servlet spec by processing the context parameter. I could
certainly
be
wrong. I'm no expert on such things.
----- Original Message ----
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 4:27:19 PM
Subject: Re: mainDecoratorLocation was Include of controllers
It seems a lot of work for simple solution
how about app-mainDecoratorLocation
then if someone want to use their own decorator it will still work.
they just define each app-mainDecoratorLocation in their web.xml
it either points to the original location or their customer
decorator.
