more specifically...
RequestHandler.java
after line 608
add:
req.setAttribute("_NEXT_PAGE", nextPage);
----- Original Message ----
From: Chris Howe <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:44:43 PM
Subject: Re: mainDecoratorLocation was Include of controllers
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 <[EMAIL PROTECTED]>
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 <[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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
>
>
>
>
>
