Re: mainDecoratorLocation and more Got it working

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

I want to give Chris Howe a big thanks for taking the time to show me my
errors.
he has a single app which does not take in to some other criteria for
accessing multiple apps.
so He did one for multiple apps.
I plan to submit the basic parts as a template patch unless someone
would rather have it in an Myapp-example

I am incorporating most of what Chris showed me in the setup app.



Jonathon -- Improov sent the following on 12/19/2007 1:06 AM:
> Also in response to BJ's "been through this umteem times"...
> 
> The idea is to provide neat encapsulation for screen widgets and their
> required "mainDecorator" params. Have a clean wrap around the 2.
> 
> When including (<include>) controller.xml of a component say "party", we
> would also be including all the <view-map>s.
> 
> Many of those <view-map>s point to screen widgets that require a
> particular "mainDecorator" to work.
> 
> Consider that your custom app includes controller.xml files from more
> than one component. Each component will require its own "mainDecorator".
> 
> Ideally, we would want to be able to reuse all <view-map>s and screen
> widgets from all included components, without having to individually
> specify which "mainDecorator" to use for which <view-map>.
> 
> BJ's suggested solution is a quick hack and alternative to the ideal
> solution. Something we may be able to develop quickly without desiging a
> full-blown space station.
> 
> Jonathon
> 
> Chris Howe wrote:
>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
> 
> 
> 
> 

Re: mainDecoratorLocation and more Got it working

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

this should be brought over when the multiple example is done.
http://ofbizwiki.go-integral.com/Wiki.jsp?page=FAQ21

BJ Freeman sent the following on 12/19/2007 4:15 PM:
> I want to give Chris Howe a big thanks for taking the time to show me my
> errors.
> he has a single app which does not take in to some other criteria for
> accessing multiple apps.
> so He did one for multiple apps.
> I plan to submit the basic parts as a template patch unless someone
> would rather have it in an Myapp-example
> 
> I am incorporating most of what Chris showed me in the setup app.
> 
> 
> 
> Jonathon -- Improov sent the following on 12/19/2007 1:06 AM:
>> Also in response to BJ's "been through this umteem times"...
>>
>> The idea is to provide neat encapsulation for screen widgets and their
>> required "mainDecorator" params. Have a clean wrap around the 2.
>>
>> When including (<include>) controller.xml of a component say "party", we
>> would also be including all the <view-map>s.
>>
>> Many of those <view-map>s point to screen widgets that require a
>> particular "mainDecorator" to work.
>>
>> Consider that your custom app includes controller.xml files from more
>> than one component. Each component will require its own "mainDecorator".
>>
>> Ideally, we would want to be able to reuse all <view-map>s and screen
>> widgets from all included components, without having to individually
>> specify which "mainDecorator" to use for which <view-map>.
>>
>> BJ's suggested solution is a quick hack and alternative to the ideal
>> solution. Something we may be able to develop quickly without desiging a
>> full-blown space station.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
>