sorry, that should be page.startsWith("component://...")
----- Original Message ----
From: Chris Howe <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:16:14 PM
Subject: Re: mainDecoratorLocation was Include of controllers
You'll need to get put the <viewmap>@page value into the context and
run a script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
<set field="applicationMenuName" value="SetupMainMenu" global="true"/>
you will have
<set field="applicationMenuName"
vlaue="${parameters.applicationMenuName}"/>
etc
----- Original Message ----
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:07:08 PM
Subject: Re: mainDecoratorLocation was Include of controllers
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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
