mainDecoratorLocation is broken and does not work as designed. was mainDecoratorLocation was Include of controllers

[BJ Freeman <bj...@free-man.net>]

Sorry I can't leave this alone.
but every reason I have been given I have shown it can not work the way
it was intended. to allow custom apps to give a a new main-decorator to
an already existing app.

So either some more work has to be done on it, like what scott has
proposed,
Adopt a simple solution.
rename the mainDecoratorLocation  to applicationname-mainDecoratorLocation
or add applicationname-mainDecoratorLocation to the context as well.
maybe add some lines in the screens that say if
applicationname-mainDecoratorLocation  is not null use
mainDecoratorLocation=applicationname-mainDecoratorLocation
this would take care of backward compatibility

I am wondering how many are actually using this feature and how.

Chris Howe sent the following on 12/17/2007 4:44 PM:
> It's already in the controller.
> 
>     <view-map name="main" type="screen" page="component://content/widget/CommonScreens.xml#main"/>
> You need to update the servlet that when it reads where to go, that it puts that value of page into the context.  Then your decorator can pull it out.
> 
> ----- Original Message ----
> From: BJ Freeman <bj...@free-man.net>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:39:46 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
> 
> 
> ah gee just found a flaw
> the <viewmap>@page value into the context
> does that go into the products or application controller.
> will that create a backward compatibility problem?
> 
> 
> 
> Chris Howe sent the following on 12/17/2007 4:28 PM:
>> sorry, that should be page.startsWith("component://...")
>> ----- Original Message ----
>> From: Chris Howe <cj...@yahoo.com>
>> 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 <bj...@free-man.net>
>> 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 <bj...@free-man.net>
>>>> 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 <bj...@free-man.net>
>>>>> 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 <bj...@free-man.net>
>>>>>> 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 <bj...@free-man.net>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 
>