yes.
Adrian Crum sent the following on 12/17/2007 4:15 PM:
> 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.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
