Re: mainDecoratorLocation was Include of controllers

[cjhowe]

Because he wants screens from the party component to be decorated with the mainDecoratorLocation defined in party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent decorated with the mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml

Adrian's solution doesn't appear to solve this problem for BJ. (I had misread the details of his explanation in saying that it had previously).  BJ requires a custom servlet that will do something like the following:

1) process as normal until it begins to process the view
2) place the <view-map>@page attribute into the context (split the screen ${screen} from the location${location})
3) render the following screen

<screen name="customScreen">
    <section>
      <actions>
           <!-- Script or service or to define mainDecoratorLocation based on value of ${location}
           ie if location=component://party/.... set parameters.mainDecoratorLocation = component://party/widget/party/CommonScreens.xml
          -->
      </actions>
      <widget>
           <include-screen name="${screen}" location="${location}"/>
      </widget>
    </section>
</screen>



----- Original Message ----
From: Scott Gray <[hidden email]>
To: [hidden email]
Sent: Monday, December 17, 2007 3:27:53 PM
Subject: Re: mainDecoratorLocation was Include of controllers


Why couldn't you supply your own custom mainDecorator?  What do the
 base
mainDecorators provide that you can't in your custom app?

Scott

On 18/12/2007, BJ Freeman <[hidden email]> wrote:
>
> Based on this, I can never see how even if I called from a custom app
> different screens in different apps how one main-decorator
> so I am not sure how this feature would work at all.
>
> Hence my original suggestion that is apps main-decorator be declared
 as
> application-mainDecoratorLocation
> this way I could include each apps mainDecoratorLocation and not have
 to
> worry
>
>
> BJ Freeman sent the following on 12/17/2007 12:55 PM:
> > I have a menu, no screens, that calls ListPartyCommEvents
> > this goes to the party controller to resolve.
> > the party controller uses it view for ListPartyCommEvents
> > It can not read the party web.xml so will error even with your
 changes.
> >
> > so lets say i put in a mainDecoratorLocation in my web xml and
 define it
> > like the one in the party commonscreens.xml
> >
> > so far so good.
> >
> > Now I call a screen in say Product. except the
 mainDecoratorLocation for
> > it has a different main-decorator. so all the requirements are not
> > defined in the party main-Decorator I have ported over.
> >
> > we still have a problem since all the apps main-decorators are not
 the

> same.
> >
> > now if the main-decorators were all the same then I could use one
> > location in any of the apps and everything would be ok
> >
> >
> >
> > Adrian Crum sent the following on 12/17/2007 12:40 PM:
> >> 1. Move the CommonCommunicationEventDecorator screen to the
> >> communicationsscreens.xml file.
> >> 2. Change all
> >> <decorator-screen name="CommonCommunicationEventDecorator"
> >> location="${parameters.mainDecoratorLocation}">
> >>
> >> to
> >>
> >> <decorator-screen name="CommonCommunicationEventDecorator"
> >> location="${parameters.communicationEventDecoratorLocation}">
> >>
> >> Since parameters.communicationEventDecoratorLocation isn't defined
> >> anywhere, the location will evaluate to the current file:
> >> communicationsscreens.xml. All communication screens still work

 the
> same
> >> in Party Manager, but now you can reuse those screens in another
 app.
> >>
> >> When you use one of the communication screens in your custom app
 (via
> >> included controller.xml file or otherwise) the
> >> parameters.communicationEventDecoratorLocation still isn't defined
> >> anywhere, so it still evaluates to the current file:
> >> communicationsscreens.xml. The communication screen and the
> >> CommonCommunicationEventDecorator will both appear - decorated
 with

> your
> >> custom app's main decorator.
> >>
> >> (Optional) If someone didn't like the
> CommonCommunicationEventDecorator,
> >> then they could design their own and specify its location in
> >> parameters.communicationEventDecoratorLocation.
> >>
> >> -Adrian
> >>
> >> BJ Freeman wrote:
> >>
> >>> Ok here is a real situation:
> >>> take the party/widgets/partymgr/commicationsscreens.xml
> >>> <decorator-screen name="CommonCommunicationEventDecorator"
> >>> location="${parameters.mainDecoratorLocation}">
> >>> which is the CommonSreens.xml
> >>> which has
> >>> <decorator-screen name="main-decorator"
> >>> location="${parameters.mainDecoratorLocation}">
> >>>
> >>> the main-decorator has
> >>>                 <include-screen name="GlobalDecorator"
> >>> location="component://common/widget/CommonScreens.xml"/>
> >>>
> >>>
> >>> how would the be with your example
> >>>
> >>>
> >>>
> >>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
> >>>
> >>>> BJ,
> >>>>
> >>>> Go ahead and create one. I will work on it when I have time.
> >>>>
> >>>> To be sure we're all on the same page, the problem exists when
> screens
> >>>> are nested as follows:
> >>>>
> >>>> <screen name="GlobalDecorator">
> >>>>  <screen name="main-decorator">
> >>>>    <screen name="sub-decorator">
> >>>>      <screen name="actual-content">
> >>>>        ...
> >>>>      </screen>
> >>>>    </screen>
> >>>>  </screen>
> >>>> </screen>
> >>>>
> >>>> and the location of the sub-decorator screen is defined as
> >>>> ${parameters.mainDecoratorLocation}. When a custom app tries to

 reuse
> >>>> the actual-content screen, errors are generated because
> >>>> <decorator-screen name="sub-decorator"
> >>>> location="${parameters.mainDecoratorLocation}"> evaluates to the
> custom
> >>>> app's main decorator xml file, and the sub-decorator screen
 doesn't
> >>>> exist there.
> >>>>
> >>>> The solution to the problem is to avoid using
> >>>> ${parameters.mainDecoratorLocation} as a location for
 sub-decorators
> and
> >>>> either have no location specified or use a different parameter
 for
> the
> >>>> sub-decorator's location - like ${subDecoratorLocation}.
> >>>>
> >>>> A good example of this approach is in AgreementScreens.xml in
 the
> >>>> Accounting component. All of the Agreement screens share a
 common
> >>>> sub-decorator (CommonAgreementDecorator) - and that decorator's
> location
> >>>> is specified as ${parameters.agreementDecoratorLocation}. The
> >>>> agreementDecoratorLocation parameter isn't defined anywhere, so
 the
> >>>> location= expression evaluates to an empty String - which causes
 the
> >>>> screen widget view handler to look for CommonAgreementDecorator
 in
> the
> >>>> existing file.
> >>>>
> >>>> A custom app that reuses one of the Agreement screens will only
 need
> to
> >>>> specify the mainDecoratorLocation parameter. Since no
> >>>> agreementDecoratorLocation parameter is defined in the custom
 app,
> the
> >>>> sub-decorator in AgreementScreens.xml is used (same as above).
 If a
> >>>> custom app wanted to have a custom sub-decorator, then it can
 specify
> >>>> that decorator's location in the agreementDecoratorLocation
> parameter.
> >>>>
> >>>> -Adrian
> >>>>
> >>>> BJ Freeman wrote:
> >>>>
> >>>>
> >>>>> I agree, it is not a controller or web.xml issue. However it is
 when

> it
> >>>>> shows up.
> >>>>> I will change them as I come along also.
> >>>>> thanks, that is all I wanted to know.
> >>>>> do you want to create a jira so I can submit changes?
> >>>>>
> >>>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
> >>>>>
> >>>>>
> >>>>>> As I mentioned before, the problem is with the coding style on

 some

> >>>>>> screens, not with the controller or web.xml files. I recently
> changed
> >>>>>> some of the accounting screens to correct this error.
> >>>>>>
> >>>>>> -Adrian
> >>>>>>
> >>>>>> BJ Freeman wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I am not really, trying to attach the context as a whole.
> >>>>>>> only trying to get the mainDecoratorLocation
> >>>>>>> which is stored as a context in web.xml.
> >>>>>>> The problem is if I put mainDecoratorLocation, in my web.xml
> >>>>>>> then all applications I call thru my controller, or the

 included
> >>>>>>> ones,
> >>>>>>> will use my mainDecoratorLocation full path.
> >>>>>>> Maybe the solution is to put the main-decorator for all apps
 in
> the
> >>>>>>> framework/commons
> >>>>>>> then like in many of the application they have specific
 decorators

> >>>>>>> that
> >>>>>>> include the main-decorator.
> >>>>>>> the problems is how to fill in the actions, etcetera
> >>>>>>>
> >>>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> All the <include> does is grab some xml elements from the
> location
> >>>>>>>> described.  Theoretically, It doesn't even need to be from

 the
> same
> >>>>>>>> server, much less the same app (may have interesting
> possibilities
> >>>>>>>> BTW).  This is why I'm having such a hard time understanding
 why

> you
> >>>>>>>> are trying to attach context to it.
> >>>>>>>>
> >>>>>>>> ----- Original Message ----
> >>>>>>>> From: BJ Freeman <[hidden email]>
> >>>>>>>> To: [hidden email]
> >>>>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM
> >>>>>>>> Subject: Re: Include of controllers
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I was going thru the trunk and noticed this in all the
> controllers
> >>>>>>>>  <include
> >>>>>>>> location="component://common/webcommon/WEB-INF/common-
> controller.xml"/>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> so there is a rule that says you can include a controller

 not in

> the
> >>>>>>>> same app.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Almost.
> >>>>>>>>> when the included controller view calles a screen in the
> partymgr
> >>>>>>>> screen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> , and that screen calls for a parm that is web.xml. the

 parm is
> not
> >>>>>>>>> availible for the screen and so fails.
> >>>>>>>>>
> >>>>>>>>> At this time, the way I handle this is to put the parm in
 my
> >>>>>>>>> Web.xml.
> >>>>>>>>>
> >>>>>>>>> My suggestions was that if a call is made to a parm that
 would
> >>>>>>>>> be in
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> applications, in this case partymgr, web.xml, that widget
 looks

> up
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> web.xml for that application to get it.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Chris Howe sent the following on 11/10/2007 2:23 PM:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Okay, I've read through the thread.  In that case, I might
> suggest
> >>>>>>>> to take a step back and look at what the two functionalities

 were
> >>>>>>>> designed to accomplish.
> >>>>>>>>
> >>>>>>>>>> Creating the mainDecoratorLocation variable in the web.xml
 was
> >>>>>>>> designed for _screen reuse. the include element in the
> >>>>>>>> controller.xml
> >>>>>>>> file
> >>>>>>>> was designed for request/response maintenance.
> >>>>>>>>
> >>>>>>>>>> With that in mind, you can include another controller in
 your
> >>>>>>>>>> custom
> >>>>>>>> application and then override the view with one that points
 to
> your
> >>>>>>>> application.   If you wish to then include a screen from
 another
> >>>>>>>> application you can use the <include-screen> element in the
> screen
> >>>>>>>> widget and
> >>>>>>>> at the same time pass a parameters.mainDecoratorLocation to
> >>>>>>>> override the
> >>>>>>>> one gained from the web.xml context of the webapp being
 used.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> It appears that what BJ is suggesting would make the
 screen
> being
> >>>>>>>> called from the ofbiz application nonreusable except as
 decorated
> >>>>>>>> as it
> >>>>>>>> is in the ofbiz project which defeats the entire purpose of
 the

> >>>>>>>> mainDecoratorLocation variable.  Do I follow correctly?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> ----- Original Message ----
> >>>>>>>>>> From: BJ Freeman <[hidden email]>
> >>>>>>>>>> To: [hidden email]
> >>>>>>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM
> >>>>>>>>>> Subject: Re: Include of controllers
> >>>>>>>>>>
> >>>>>>>>>> Chris the discussion is about using the include in the
> controller.
> >>>>>>>>>> and that the current way of putting the locations of

 parameters

> >>>>>>>>>> used
> >>>>>>>> in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> the widgets for screen decorators is causing a problem
> >>>>>>>>>> In a lot of apps the location is called out in the web.xml
> >>>>>>>>>> <context-param>
> >>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
> >>>>>>>>>>
> >>>>>>>>
>

 <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>   <description>The location of the main-decorator screen
 to use
> >>>>>>>> for
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> this webapp; referred to as a context variable in screen
 def
> XML
> >>>>>>>>>> files.</description>
> >>>>>>>>>> </context-param>
> >>>>>>>>>>
> >>>>>>>>>> The suggeston is to take the location out to the web.xml
 and
> >>>>>>>>>> put in
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> widget like so.
> >>>>>>>>>>
> >>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
> >>>>>>>>>>
 location="component://party/widget/partymgr/CommonScreens.xml">
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I haven't been following the thread, but instead of
 setting it
> >>>>>>>>>> explicitly in the widgets section, you may prefer to
 define it

> in
> >>>>>>>> the actions
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> section...
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> <action>
> >>>>>>>>>>> <set field="parameters.mainDecoratorLocation"
> >>>>>>>>>>

 value="component://party/widget/partymgr/CommonScreens.xml"/>

> >>>>>>>>>>
> >>>>>>>>>>> </action>
> >>>>>>>>>>> <widget>
> >>>>>>>>>>> <include-screen name="splitScreen"/>
> >>>>>>>>>>> </widget>
> >>>>>>>>>>> ...
> >>>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
> >>>>>>>>>> location="${parameters.mainDecoratorLocation}">
> >>>>>>>>>>
> >>>>>>>>>>> <screen name="splitScreen">
> >>>>>>>>>>> ...
> >>>>>>>>>>> <widget>
> >>>>>>>>>>>
> >>>>>>>>>>> </widget>
> >>>>>>>>>>> ...
> >>>>>>>>>>> or something similar that it remains a variable so that

 you
> can
> >>>>>>>> later
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> split the widget section out to be it's own screen so that
 it
> can
> >>>>>>>> be
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> used with the decorator in another webapp.  I don't know
 if the
> >>>>>>>> screens
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> you're worried  about here are that complex.  This has
 been a

> >>>>>>>> better
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> pattern for me.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> ----- Original Message ----
> >>>>>>>>>>> From: BJ Freeman <[hidden email]>
> >>>>>>>>>>> To: [hidden email]
> >>>>>>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM
> >>>>>>>>>>> Subject: Re: Include of controllers
> >>>>>>>>>>>
> >>>>>>>>>>> Just want to make sure we are all on the same page
> >>>>>>>>>>> in a widget screen
> >>>>>>>>>>>              <decorator-screen

 name="CommonPartyDecorator"
> >>>>>>>>>>> location="${parameters.mainDecoratorLocation}">
> >>>>>>>>>>>
> >>>>>>>>>>> parameters.mainDecoratorLocation is in the Web.xml
> >>>>>>>>>>>
> >>>>>>>>>>> <context-param>
> >>>>>>>>>>>  <param-name>mainDecoratorLocation</param-name>
> >>>>>>>>>>>
> >>>>>>>>
>
 <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>  <description>The location of the main-decorator screen
 to use
> >>>>>>>> for
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> this webapp; referred to as a context variable in screen
 def
> XML
> >>>>>>>>>>> files.</description>
> >>>>>>>>>>> </context-param>
> >>>>>>>>>>>
> >>>>>>>>>>> so to "fix"
> >>>>>>>>>>>              <decorator-screen
 name="CommonPartyDecorator"

> >>>>>>>>>>>
> location="component://party/widget/partymgr/CommonScreens.xml">
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Ok so the code that allows the context to be used in the
> web.xml
> >>>>>>>> is
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>> being depreciated?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> BJ,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nothing is being reversed. You have pointed out a

 weakness
> >>>>>>>>>>>>> in how
> >>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> some of the party manager screens are set up (they
 can't be
> >>>>>>>>>> reused).
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> I
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> have confirmed they have a problem. So submitting a
 patch

> FIXES
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>> issue - it doesn't reverse anything.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Adrian
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> BJ Freeman wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I will not submit a patch for what I am proposing,

 like a
> >>>>>>>>>>>>>> lot of
> >>>>>>>>>> my
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>> code, it stays in the applications I am doing.
> >>>>>>>>>>>>>> and since someone else put effort into what is in
 ofbiz now

> >>>>>>>>>>>>>> I do not plan to put effort into reversing it.
> >>>>>>>>>>>>>> :)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> BJ,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> As I mentioned before, I believe it would be

 better/easier

> to
> >>>>>>>> fix
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> party manager screens. Including web.xml files will

 open

> up a
> >>>>>>>> big
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> can of
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> worms.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Adrian
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> BJ Freeman wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hans:
> >>>>>>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator
> location
> >>>>>>>> in
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> the
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> context in web.xml
> >>>>>>>>>>>>>>>> this was done by someone else and is a standard

 through

> >>>>>>>>>>>>>>>> ofbiz
> >>>>>>>> as
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> far as
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> i can tell.
> >>>>>>>>>>>>>>>> I take the path of least resistance.
> >>>>>>>>>>>>>>>> Since it is possible to put context in the web.xml

 and
> >>>>>>>>>>>>>>>> someone
> >>>>>>>>>>> has
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> put a
> >>>>>>>>>>>>>>>> lot of effort into refactoring ofbiz to this
 standard, I
> >>>>>>>>>>>>>>>> have
> >>>>>>>> no
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>> intention of undoing it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> so my focus for my code will be to have the
 web.xmlincluded
> >>>>>>>> as
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> well,
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> unless the powers to be say there is going to be a
 change

> in
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> best
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> practices.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hi Bj,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> request (or provide a patch) that the
> >>>>>>>>>>>>>>>>> CommonCommunicationEventDecorator
> >>>>>>>>>>>>>>>>> is moved to the xml file as defined in the web.xml
> >>>>>>>>>>>>>>>>> parameter.
> >>>>>>>>>>> Also
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>> request that the 'location' parameter is defined in

 the

> >>>>>>>> screen
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> you are
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>> using.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Then you can use this screen in your own

 application

> using
> >>>>>>>> your
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> own
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>> decorator.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>> Hans
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman

 wrote:

> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I have a controller.xml
> >>>>>>>>>>>>>>>>>> it has the include for the partymgr in it.
> >>>>>>>>>>>>>>>>>> I have a menu widget that calls the partmgr
> >>>>>>>>>>>>>>>>>> I have the PartymgrDecoratorLocation in my web.xml
> >>>>>>>>>>>>>>>>>> so I get to the find screen OK.
> >>>>>>>>>>>>>>>>>> I have a few others in my web.xml as well.
> >>>>>>>>>>>>>>>>>> so I can navigate.
> >>>>>>>>>>>>>>>>>> however if you don't have these in your web.xml

 that is

> in
> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> same
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> directory as the controller.xml you are using
> >>>>>>>>>>>>>>>>>> https://localhost:8443/myapp/control/partymgr
> >>>>>>>>>>>>>>>>>> then you get messages like this.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> org.ofbiz.base.util.GeneralException: Error

 rendering
> >>>>>>>>>>>>>>>>>> screen
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
>
 [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:

> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find
> screen
> >>>>>>>> with
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> name
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same

 file as
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>> screen
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find
 screen
> with
> >>>>>>>> name
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same
 file as

> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>> screen
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> name [EditCommunicationEvent])
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> BJ,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Do you have any specific examples of what you're
> >>>>>>>>>>>>>>>>>> describing?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -Adrian
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:59

 PM:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> sorry not a complete thougt
> >>>>>>>>>>>>>>>>>>> This is not a real bug.
> >>>>>>>>>>>>>>>>>>> when you included another contorller
> >>>>>>>>>>>>>>>>>>> and there is a commonscreen.xml defined in the
 web.xmlof

> >>>>>>>> the
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>>> controller application it causes an error.
> >>>>>>>>>>>>>>>>>>> so maybe puttting the application name before
> >>>>>>>> commonescreens
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> will
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> eliminate that.
> >>>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55

 PM:

> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> This is not a real bug.
> >>>>>>>>>>>>>>>>>>>> when you included another contorller
> >>>>>>>>>>>>>>>>>>>> and it has a commonscreen.xml
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> another is that when the the other widget from

 the
> >>>>>>>> included
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>>>> controller
> >>>>>>>>>>>>>>>>>>>> calls for a context that is in the web.xml of
 that

> >>>>>>>>>>> application.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> it is not found.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>

[Adrian Crum]

If all BJ wants to do is display an existing screen with its existing main decorator, then he can
just use the screen's URL.

Chris Howe wrote:

> Because he wants screens from the party component to be decorated with the mainDecoratorLocation defined in party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent decorated with the mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml
>
> Adrian's solution doesn't appear to solve this problem for BJ. (I had misread the details of his explanation in saying that it had previously).  BJ requires a custom servlet that will do something like the following:
>
> 1) process as normal until it begins to process the view
> 2) place the <view-map>@page attribute into the context (split the screen ${screen} from the location${location})
> 3) render the following screen
>
> <screen name="customScreen">
>     <section>
>       <actions>
>            <!-- Script or service or to define mainDecoratorLocation based on value of ${location}
>            ie if location=component://party/.... set parameters.mainDecoratorLocation = component://party/widget/party/CommonScreens.xml
>           -->
>       </actions>
>       <widget>
>            <include-screen name="${screen}" location="${location}"/>
>       </widget>
>     </section>
> </screen>
>
>
>
> ----- Original Message ----
> From: Scott Gray <[hidden email]>
> To: [hidden email]
> Sent: Monday, December 17, 2007 3:27:53 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> Why couldn't you supply your own custom mainDecorator?  What do the
>  base
> mainDecorators provide that you can't in your custom app?
>
> Scott
>
> On 18/12/2007, BJ Freeman <[hidden email]> wrote:
>
>>Based on this, I can never see how even if I called from a custom app
>>different screens in different apps how one main-decorator
>>so I am not sure how this feature would work at all.
>>
>>Hence my original suggestion that is apps main-decorator be declared
>
>  as
>
>>application-mainDecoratorLocation
>>this way I could include each apps mainDecoratorLocation and not have
>
>  to
>
>>worry
>>
>>
>>BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>
>>>I have a menu, no screens, that calls ListPartyCommEvents
>>>this goes to the party controller to resolve.
>>>the party controller uses it view for ListPartyCommEvents
>>>It can not read the party web.xml so will error even with your
>
>  changes.
>
>>>so lets say i put in a mainDecoratorLocation in my web xml and
>
>  define it
>
>>>like the one in the party commonscreens.xml
>>>
>>>so far so good.
>>>
>>>Now I call a screen in say Product. except the
>
>  mainDecoratorLocation for
>
>>>it has a different main-decorator. so all the requirements are not
>>>defined in the party main-Decorator I have ported over.
>>>
>>>we still have a problem since all the apps main-decorators are not
>
>  the
>
>>same.
>>
>>>now if the main-decorators were all the same then I could use one
>>>location in any of the apps and everything would be ok
>>>
>>>
>>>
>>>Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>>
>>>>1. Move the CommonCommunicationEventDecorator screen to the
>>>>communicationsscreens.xml file.
>>>>2. Change all
>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>location="${parameters.mainDecoratorLocation}">
>>>>
>>>>to
>>>>
>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>location="${parameters.communicationEventDecoratorLocation}">
>>>>
>>>>Since parameters.communicationEventDecoratorLocation isn't defined
>>>>anywhere, the location will evaluate to the current file:
>>>>communicationsscreens.xml. All communication screens still work
>
>  the
>
>>same
>>
>>>>in Party Manager, but now you can reuse those screens in another
>
>  app.
>
>>>>When you use one of the communication screens in your custom app
>
>  (via
>
>>>>included controller.xml file or otherwise) the
>>>>parameters.communicationEventDecoratorLocation still isn't defined
>>>>anywhere, so it still evaluates to the current file:
>>>>communicationsscreens.xml. The communication screen and the
>>>>CommonCommunicationEventDecorator will both appear - decorated
>
>  with
>
>>your
>>
>>>>custom app's main decorator.
>>>>
>>>>(Optional) If someone didn't like the
>>
>>CommonCommunicationEventDecorator,
>>
>>>>then they could design their own and specify its location in
>>>>parameters.communicationEventDecoratorLocation.
>>>>
>>>>-Adrian
>>>>
>>>>BJ Freeman wrote:
>>>>
>>>>
>>>>>Ok here is a real situation:
>>>>>take the party/widgets/partymgr/commicationsscreens.xml
>>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>which is the CommonSreens.xml
>>>>>which has
>>>>><decorator-screen name="main-decorator"
>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>
>>>>>the main-decorator has
>>>>>                <include-screen name="GlobalDecorator"
>>>>>location="component://common/widget/CommonScreens.xml"/>
>>>>>
>>>>>
>>>>>how would the be with your example
>>>>>
>>>>>
>>>>>
>>>>>Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>>>
>>>>>
>>>>>>BJ,
>>>>>>
>>>>>>Go ahead and create one. I will work on it when I have time.
>>>>>>
>>>>>>To be sure we're all on the same page, the problem exists when
>>
>>screens
>>
>>>>>>are nested as follows:
>>>>>>
>>>>>><screen name="GlobalDecorator">
>>>>>> <screen name="main-decorator">
>>>>>>   <screen name="sub-decorator">
>>>>>>     <screen name="actual-content">
>>>>>>       ...
>>>>>>     </screen>
>>>>>>   </screen>
>>>>>> </screen>
>>>>>></screen>
>>>>>>
>>>>>>and the location of the sub-decorator screen is defined as
>>>>>>${parameters.mainDecoratorLocation}. When a custom app tries to
>
>  reuse
>
>>>>>>the actual-content screen, errors are generated because
>>>>>><decorator-screen name="sub-decorator"
>>>>>>location="${parameters.mainDecoratorLocation}"> evaluates to the
>>
>>custom
>>
>>>>>>app's main decorator xml file, and the sub-decorator screen
>
>  doesn't
>
>>>>>>exist there.
>>>>>>
>>>>>>The solution to the problem is to avoid using
>>>>>>${parameters.mainDecoratorLocation} as a location for
>
>  sub-decorators
>
>>and
>>
>>>>>>either have no location specified or use a different parameter
>
>  for
>
>>the
>>
>>>>>>sub-decorator's location - like ${subDecoratorLocation}.
>>>>>>
>>>>>>A good example of this approach is in AgreementScreens.xml in
>
>  the
>
>>>>>>Accounting component. All of the Agreement screens share a
>
>  common
>
>>>>>>sub-decorator (CommonAgreementDecorator) - and that decorator's
>>
>>location
>>
>>>>>>is specified as ${parameters.agreementDecoratorLocation}. The
>>>>>>agreementDecoratorLocation parameter isn't defined anywhere, so
>
>  the
>
>>>>>>location= expression evaluates to an empty String - which causes
>
>  the
>
>>>>>>screen widget view handler to look for CommonAgreementDecorator
>
>  in
>
>>the
>>
>>>>>>existing file.
>>>>>>
>>>>>>A custom app that reuses one of the Agreement screens will only
>
>  need
>
>>to
>>
>>>>>>specify the mainDecoratorLocation parameter. Since no
>>>>>>agreementDecoratorLocation parameter is defined in the custom
>
>  app,
>
>>the
>>
>>>>>>sub-decorator in AgreementScreens.xml is used (same as above).
>
>  If a
>
>>>>>>custom app wanted to have a custom sub-decorator, then it can
>
>  specify
>
>>>>>>that decorator's location in the agreementDecoratorLocation
>>
>>parameter.
>>
>>>>>>-Adrian
>>>>>>
>>>>>>BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I agree, it is not a controller or web.xml issue. However it is
>
>  when
>
>>it
>>
>>>>>>>shows up.
>>>>>>>I will change them as I come along also.
>>>>>>>thanks, that is all I wanted to know.
>>>>>>>do you want to create a jira so I can submit changes?
>>>>>>>
>>>>>>>Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>As I mentioned before, the problem is with the coding style on
>
>  some
>
>>>>>>>>screens, not with the controller or web.xml files. I recently
>>
>>changed
>>
>>>>>>>>some of the accounting screens to correct this error.
>>>>>>>>
>>>>>>>>-Adrian
>>>>>>>>
>>>>>>>>BJ Freeman wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I am not really, trying to attach the context as a whole.
>>>>>>>>>only trying to get the mainDecoratorLocation
>>>>>>>>>which is stored as a context in web.xml.
>>>>>>>>>The problem is if I put mainDecoratorLocation, in my web.xml
>>>>>>>>>then all applications I call thru my controller, or the
>
>  included
>
>>>>>>>>>ones,
>>>>>>>>>will use my mainDecoratorLocation full path.
>>>>>>>>>Maybe the solution is to put the main-decorator for all apps
>
>  in
>
>>the
>>
>>>>>>>>>framework/commons
>>>>>>>>>then like in many of the application they have specific
>
>  decorators
>
>>>>>>>>>that
>>>>>>>>>include the main-decorator.
>>>>>>>>>the problems is how to fill in the actions, etcetera
>>>>>>>>>
>>>>>>>>>Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>All the <include> does is grab some xml elements from the
>>
>>location
>>
>>>>>>>>>>described.  Theoretically, It doesn't even need to be from
>
>  the
>
>>same
>>
>>>>>>>>>>server, much less the same app (may have interesting
>>
>>possibilities
>>
>>>>>>>>>>BTW).  This is why I'm having such a hard time understanding
>
>  why
>
>>you
>>
>>>>>>>>>>are trying to attach context to it.
>>>>>>>>>>
>>>>>>>>>>----- Original Message ----
>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>To: [hidden email]
>>>>>>>>>>Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>I was going thru the trunk and noticed this in all the
>>
>>controllers
>>
>>>>>>>>>> <include
>>>>>>>>>>location="component://common/webcommon/WEB-INF/common-
>>
>>controller.xml"/>
>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>so there is a rule that says you can include a controller
>
>  not in
>
>>the
>>
>>>>>>>>>>same app.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Almost.
>>>>>>>>>>>when the included controller view calles a screen in the
>>
>>partymgr
>>
>>>>>>>>>>screen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>, and that screen calls for a parm that is web.xml. the
>
>  parm is
>
>>not
>>
>>>>>>>>>>>availible for the screen and so fails.
>>>>>>>>>>>
>>>>>>>>>>>At this time, the way I handle this is to put the parm in
>
>  my
>
>>>>>>>>>>>Web.xml.
>>>>>>>>>>>
>>>>>>>>>>>My suggestions was that if a call is made to a parm that
>
>  would
>
>>>>>>>>>>>be in
>>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>applications, in this case partymgr, web.xml, that widget
>
>  looks
>
>>up
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>web.xml for that application to get it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Okay, I've read through the thread.  In that case, I might
>>
>>suggest
>>
>>>>>>>>>>to take a step back and look at what the two functionalities
>
>  were
>
>>>>>>>>>>designed to accomplish.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>Creating the mainDecoratorLocation variable in the web.xml
>
>  was
>
>>>>>>>>>>designed for _screen reuse. the include element in the
>>>>>>>>>>controller.xml
>>>>>>>>>>file
>>>>>>>>>>was designed for request/response maintenance.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>With that in mind, you can include another controller in
>
>  your
>
>>>>>>>>>>>>custom
>>>>>>>>>>
>>>>>>>>>>application and then override the view with one that points
>
>  to
>
>>your
>>
>>>>>>>>>>application.   If you wish to then include a screen from
>
>  another
>
>>>>>>>>>>application you can use the <include-screen> element in the
>>
>>screen
>>
>>>>>>>>>>widget and
>>>>>>>>>>at the same time pass a parameters.mainDecoratorLocation to
>>>>>>>>>>override the
>>>>>>>>>>one gained from the web.xml context of the webapp being
>
>  used.
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>It appears that what BJ is suggesting would make the
>
>  screen
>
>>being
>>
>>>>>>>>>>called from the ofbiz application nonreusable except as
>
>  decorated
>
>>>>>>>>>>as it
>>>>>>>>>>is in the ofbiz project which defeats the entire purpose of
>
>  the
>
>>>>>>>>>>mainDecoratorLocation variable.  Do I follow correctly?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>----- Original Message ----
>>>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>To: [hidden email]
>>>>>>>>>>>>Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>>>
>>>>>>>>>>>>Chris the discussion is about using the include in the
>>
>>controller.
>>
>>>>>>>>>>>>and that the current way of putting the locations of
>
>  parameters
>
>>>>>>>>>>>>used
>>>>>>>>>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the widgets for screen decorators is causing a problem
>>>>>>>>>>>>In a lot of apps the location is called out in the web.xml
>>>>>>>>>>>><context-param>
>>>>>>>>>>>><param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>
>  <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>  <description>The location of the main-decorator screen
>
>  to use
>
>>>>>>>>>>for
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>this webapp; referred to as a context variable in screen
>
>  def
>
>>XML
>>
>>>>>>>>>>>>files.</description>
>>>>>>>>>>>></context-param>
>>>>>>>>>>>>
>>>>>>>>>>>>The suggeston is to take the location out to the web.xml
>
>  and
>
>>>>>>>>>>>>put in
>>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>widget like so.
>>>>>>>>>>>>
>>>>>>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>
>
>  location="component://party/widget/partymgr/CommonScreens.xml">
>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>I haven't been following the thread, but instead of
>
>  setting it
>
>>>>>>>>>>>>explicitly in the widgets section, you may prefer to
>
>  define it
>
>>in
>>
>>>>>>>>>>the actions
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>section...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>><action>
>>>>>>>>>>>>><set field="parameters.mainDecoratorLocation"
>>>>>>>>>>>>
>  value="component://party/widget/partymgr/CommonScreens.xml"/>
>
>>>>>>>>>>>>></action>
>>>>>>>>>>>>><widget>
>>>>>>>>>>>>><include-screen name="splitScreen"/>
>>>>>>>>>>>>></widget>
>>>>>>>>>>>>>...
>>>>>>>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>
>>>>>>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>
>>>>>>>>>>>>><screen name="splitScreen">
>>>>>>>>>>>>>...
>>>>>>>>>>>>><widget>
>>>>>>>>>>>>>
>>>>>>>>>>>>></widget>
>>>>>>>>>>>>>...
>>>>>>>>>>>>>or something similar that it remains a variable so that
>
>  you
>
>>can
>>
>>>>>>>>>>later
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>split the widget section out to be it's own screen so that
>
>  it
>
>>can
>>
>>>>>>>>>>be
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>used with the decorator in another webapp.  I don't know
>
>  if the
>
>>>>>>>>>>screens
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>you're worried  about here are that complex.  This has
>
>  been a
>
>>>>>>>>>>better
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>pattern for me.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>----- Original Message ----
>>>>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>>To: [hidden email]
>>>>>>>>>>>>>Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>>>>
>>>>>>>>>>>>>Just want to make sure we are all on the same page
>>>>>>>>>>>>>in a widget screen
>>>>>>>>>>>>>             <decorator-screen
>
>  name="CommonPartyDecorator"
>
>>>>>>>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>>
>>>>>>>>>>>>>parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>>>>>>
>>>>>>>>>>>>><context-param>
>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>>
>  <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> <description>The location of the main-decorator screen
>
>  to use
>
>>>>>>>>>>for
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>this webapp; referred to as a context variable in screen
>
>  def
>
>>XML
>>
>>>>>>>>>>>>>files.</description>
>>>>>>>>>>>>></context-param>
>>>>>>>>>>>>>
>>>>>>>>>>>>>so to "fix"
>>>>>>>>>>>>>             <decorator-screen
>
>  name="CommonPartyDecorator"
>
>>location="component://party/widget/partymgr/CommonScreens.xml">
>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>Ok so the code that allows the context to be used in the
>>
>>web.xml
>>
>>>>>>>>>>is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>being depreciated?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Nothing is being reversed. You have pointed out a
>
>  weakness
>
>>>>>>>>>>>>>>>in how
>>>>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>some of the party manager screens are set up (they
>
>  can't be
>
>>>>>>>>>>>>reused).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>I
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>have confirmed they have a problem. So submitting a
>
>  patch
>
>>FIXES
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>issue - it doesn't reverse anything.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I will not submit a patch for what I am proposing,
>
>  like a
>
>>>>>>>>>>>>>>>>lot of
>>>>>>>>>>>>
>>>>>>>>>>>>my
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>code, it stays in the applications I am doing.
>>>>>>>>>>>>>>>>and since someone else put effort into what is in
>
>  ofbiz now
>
>>>>>>>>>>>>>>>>I do not plan to put effort into reversing it.
>>>>>>>>>>>>>>>>:)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>As I mentioned before, I believe it would be
>
>  better/easier
>
>>to
>>
>>>>>>>>>>fix
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>party manager screens. Including web.xml files will
>
>  open
>
>>up a
>>
>>>>>>>>>>big
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>can of
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>worms.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Hans:
>>>>>>>>>>>>>>>>>>I did not put the CommonCommunicationEventDecorator
>>
>>location
>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>context in web.xml
>>>>>>>>>>>>>>>>>>this was done by someone else and is a standard
>
>  through
>
>>>>>>>>>>>>>>>>>>ofbiz
>>>>>>>>>>
>>>>>>>>>>as
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>far as
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>i can tell.
>>>>>>>>>>>>>>>>>>I take the path of least resistance.
>>>>>>>>>>>>>>>>>>Since it is possible to put context in the web.xml
>
>  and
>
>>>>>>>>>>>>>>>>>>someone
>>>>>>>>>>>>>
>>>>>>>>>>>>>has
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>put a
>>>>>>>>>>>>>>>>>>lot of effort into refactoring ofbiz to this
>
>  standard, I
>
>>>>>>>>>>>>>>>>>>have
>>>>>>>>>>
>>>>>>>>>>no
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>intention of undoing it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>so my focus for my code will be to have the
>
>  web.xmlincluded
>
>>>>>>>>>>as
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>well,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>unless the powers to be say there is going to be a
>
>  change
>
>>in
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>best
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>practices.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Hi Bj,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>request (or provide a patch) that the
>>>>>>>>>>>>>>>>>>>CommonCommunicationEventDecorator
>>>>>>>>>>>>>>>>>>>is moved to the xml file as defined in the web.xml
>>>>>>>>>>>>>>>>>>>parameter.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Also
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>request that the 'location' parameter is defined in
>
>  the
>
>>>>>>>>>>screen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>you are
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>using.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Then you can use this screen in your own
>
>  application
>
>>using
>>
>>>>>>>>>>your
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>own
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>decorator.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Regards,
>>>>>>>>>>>>>>>>>>>Hans
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman
>
>  wrote:
>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>I have a controller.xml
>>>>>>>>>>>>>>>>>>>>it has the include for the partymgr in it.
>>>>>>>>>>>>>>>>>>>>I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>>>>>>>I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>>>>>>>so I get to the find screen OK.
>>>>>>>>>>>>>>>>>>>>I have a few others in my web.xml as well.
>>>>>>>>>>>>>>>>>>>>so I can navigate.
>>>>>>>>>>>>>>>>>>>>however if you don't have these in your web.xml
>
>  that is
>
>>in
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>same
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>directory as the controller.xml you are using
>>>>>>>>>>>>>>>>>>>>https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>>>>>>>then you get messages like this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>org.ofbiz.base.util.GeneralException: Error
>
>  rendering
>
>>>>>>>>>>>>>>>>>>>>screen
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>  [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>java.lang.IllegalArgumentException: Could not find
>>
>>screen
>>
>>>>>>>>>>with
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>name
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same
>
>  file as
>
>>>>>>>>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>screen
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>>>>>>name [EditCommunicationEvent] (Could not find
>
>  screen
>
>>with
>>
>>>>>>>>>>name
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same
>
>  file as
>
>>>>>>>>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>screen
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>>>>>>name [EditCommunicationEvent])
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>Do you have any specific examples of what you're
>>>>>>>>>>>>>>>>>>>>describing?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:59
>
>  PM:
>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>sorry not a complete thougt
>>>>>>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>>>>>>and there is a commonscreen.xml defined in the
>
>  web.xmlof
>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>calling
>>>>>>>>>>>>>>>>>>>>>controller application it causes an error.
>>>>>>>>>>>>>>>>>>>>>so maybe puttting the application name before
>>>>>>>>>>
>>>>>>>>>>commonescreens
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>will
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>eliminate that.
>>>>>>>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:55
>
>  PM:
>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>>>>>>>and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>another is that when the the other widget from
>
>  the
>
>>>>>>>>>>included
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>controller
>>>>>>>>>>>>>>>>>>>>>>calls for a context that is in the web.xml of
>
>  that
>
>>>>>>>>>>>>>application.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>it is not found.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>

[cjhowe]

I suggested that as well and Scott echoed it. It doesn't seem to be satisfactory to BJ.  So we work at it.

----- Original Message ----
From: Adrian Crum <[hidden email]>
To: [hidden email]
Sent: Monday, December 17, 2007 3:57:53 PM
Subject: Re: mainDecoratorLocation was Include of controllers


If all BJ wants to do is display an existing screen with its existing
 main decorator, then he can
just use the screen's URL.

Chris Howe wrote:

> Because he wants screens from the party component to be decorated
 with the mainDecoratorLocation defined in
 party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent decorated with the
 mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml
>
> Adrian's solution doesn't appear to solve this problem for BJ. (I had
 misread the details of his explanation in saying that it had
 previously).  BJ requires a custom servlet that will do something like the
 following:
>
> 1) process as normal until it begins to process the view
> 2) place the <view-map>@page attribute into the context (split the
 screen ${screen} from the location${location})
> 3) render the following screen
>
> <screen name="customScreen">
>     <section>
>       <actions>
>            <!-- Script or service or to define mainDecoratorLocation
 based on value of ${location}
>            ie if location=component://party/.... set
 parameters.mainDecoratorLocation = component://party/widget/party/CommonScreens.xml

>           -->
>       </actions>
>       <widget>
>            <include-screen name="${screen}" location="${location}"/>
>       </widget>
>     </section>
> </screen>
>
>
>
> ----- Original Message ----
> From: Scott Gray <[hidden email]>
> To: [hidden email]
> Sent: Monday, December 17, 2007 3:27:53 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> Why couldn't you supply your own custom mainDecorator?  What do the
>  base
> mainDecorators provide that you can't in your custom app?
>
> Scott
>
> On 18/12/2007, BJ Freeman <[hidden email]> wrote:
>
>>Based on this, I can never see how even if I called from a custom app
>>different screens in different apps how one main-decorator
>>so I am not sure how this feature would work at all.
>>
>>Hence my original suggestion that is apps main-decorator be declared
>
>  as
>
>>application-mainDecoratorLocation
>>this way I could include each apps mainDecoratorLocation and not have
>
>  to
>
>>worry
>>
>>
>>BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>
>>>I have a menu, no screens, that calls ListPartyCommEvents
>>>this goes to the party controller to resolve.
>>>the party controller uses it view for ListPartyCommEvents
>>>It can not read the party web.xml so will error even with your
>
>  changes.
>
>>>so lets say i put in a mainDecoratorLocation in my web xml and
>
>  define it
>
>>>like the one in the party commonscreens.xml
>>>
>>>so far so good.
>>>
>>>Now I call a screen in say Product. except the
>
>  mainDecoratorLocation for
>
>>>it has a different main-decorator. so all the requirements are not
>>>defined in the party main-Decorator I have ported over.
>>>
>>>we still have a problem since all the apps main-decorators are not
>
>  the
>
>>same.
>>
>>>now if the main-decorators were all the same then I could use one
>>>location in any of the apps and everything would be ok
>>>
>>>
>>>
>>>Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>>
>>>>1. Move the CommonCommunicationEventDecorator screen to the
>>>>communicationsscreens.xml file.
>>>>2. Change all
>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>location="${parameters.mainDecoratorLocation}">
>>>>
>>>>to
>>>>
>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>location="${parameters.communicationEventDecoratorLocation}">
>>>>
>>>>Since parameters.communicationEventDecoratorLocation isn't defined
>>>>anywhere, the location will evaluate to the current file:
>>>>communicationsscreens.xml. All communication screens still work
>
>  the
>
>>same
>>
>>>>in Party Manager, but now you can reuse those screens in another
>
>  app.
>
>>>>When you use one of the communication screens in your custom app
>
>  (via
>
>>>>included controller.xml file or otherwise) the
>>>>parameters.communicationEventDecoratorLocation still isn't defined
>>>>anywhere, so it still evaluates to the current file:
>>>>communicationsscreens.xml. The communication screen and the
>>>>CommonCommunicationEventDecorator will both appear - decorated
>
>  with
>
>>your
>>
>>>>custom app's main decorator.
>>>>
>>>>(Optional) If someone didn't like the
>>
>>CommonCommunicationEventDecorator,
>>
>>>>then they could design their own and specify its location in
>>>>parameters.communicationEventDecoratorLocation.
>>>>
>>>>-Adrian
>>>>
>>>>BJ Freeman wrote:
>>>>
>>>>
>>>>>Ok here is a real situation:
>>>>>take the party/widgets/partymgr/commicationsscreens.xml
>>>>><decorator-screen name="CommonCommunicationEventDecorator"
>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>which is the CommonSreens.xml
>>>>>which has
>>>>><decorator-screen name="main-decorator"
>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>
>>>>>the main-decorator has
>>>>>                <include-screen name="GlobalDecorator"
>>>>>location="component://common/widget/CommonScreens.xml"/>
>>>>>
>>>>>
>>>>>how would the be with your example
>>>>>
>>>>>
>>>>>
>>>>>Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>>>
>>>>>
>>>>>>BJ,
>>>>>>
>>>>>>Go ahead and create one. I will work on it when I have time.
>>>>>>
>>>>>>To be sure we're all on the same page, the problem exists when
>>
>>screens
>>
>>>>>>are nested as follows:
>>>>>>
>>>>>><screen name="GlobalDecorator">
>>>>>> <screen name="main-decorator">
>>>>>>   <screen name="sub-decorator">
>>>>>>     <screen name="actual-content">
>>>>>>       ...
>>>>>>     </screen>
>>>>>>   </screen>
>>>>>> </screen>
>>>>>></screen>
>>>>>>
>>>>>>and the location of the sub-decorator screen is defined as
>>>>>>${parameters.mainDecoratorLocation}. When a custom app tries to
>
>  reuse
>
>>>>>>the actual-content screen, errors are generated because
>>>>>><decorator-screen name="sub-decorator"
>>>>>>location="${parameters.mainDecoratorLocation}"> evaluates to the
>>
>>custom
>>
>>>>>>app's main decorator xml file, and the sub-decorator screen
>
>  doesn't
>
>>>>>>exist there.
>>>>>>
>>>>>>The solution to the problem is to avoid using
>>>>>>${parameters.mainDecoratorLocation} as a location for
>
>  sub-decorators
>
>>and
>>
>>>>>>either have no location specified or use a different parameter
>
>  for
>
>>the
>>
>>>>>>sub-decorator's location - like ${subDecoratorLocation}.
>>>>>>
>>>>>>A good example of this approach is in AgreementScreens.xml in
>
>  the
>
>>>>>>Accounting component. All of the Agreement screens share a
>
>  common
>
>>>>>>sub-decorator (CommonAgreementDecorator) - and that decorator's
>>
>>location
>>
>>>>>>is specified as ${parameters.agreementDecoratorLocation}. The
>>>>>>agreementDecoratorLocation parameter isn't defined anywhere, so
>
>  the
>
>>>>>>location= expression evaluates to an empty String - which causes
>
>  the
>
>>>>>>screen widget view handler to look for CommonAgreementDecorator
>
>  in
>
>>the
>>
>>>>>>existing file.
>>>>>>
>>>>>>A custom app that reuses one of the Agreement screens will only
>
>  need
>
>>to
>>
>>>>>>specify the mainDecoratorLocation parameter. Since no
>>>>>>agreementDecoratorLocation parameter is defined in the custom
>
>  app,
>
>>the
>>
>>>>>>sub-decorator in AgreementScreens.xml is used (same as above).
>
>  If a
>
>>>>>>custom app wanted to have a custom sub-decorator, then it can
>
>  specify
>
>>>>>>that decorator's location in the agreementDecoratorLocation
>>
>>parameter.
>>
>>>>>>-Adrian
>>>>>>
>>>>>>BJ Freeman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I agree, it is not a controller or web.xml issue. However it is
>
>  when
>
>>it
>>
>>>>>>>shows up.
>>>>>>>I will change them as I come along also.
>>>>>>>thanks, that is all I wanted to know.
>>>>>>>do you want to create a jira so I can submit changes?
>>>>>>>
>>>>>>>Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>As I mentioned before, the problem is with the coding style on
>
>  some
>
>>>>>>>>screens, not with the controller or web.xml files. I recently
>>
>>changed
>>
>>>>>>>>some of the accounting screens to correct this error.
>>>>>>>>
>>>>>>>>-Adrian
>>>>>>>>
>>>>>>>>BJ Freeman wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I am not really, trying to attach the context as a whole.
>>>>>>>>>only trying to get the mainDecoratorLocation
>>>>>>>>>which is stored as a context in web.xml.
>>>>>>>>>The problem is if I put mainDecoratorLocation, in my web.xml
>>>>>>>>>then all applications I call thru my controller, or the
>
>  included
>
>>>>>>>>>ones,
>>>>>>>>>will use my mainDecoratorLocation full path.
>>>>>>>>>Maybe the solution is to put the main-decorator for all apps
>
>  in
>
>>the
>>
>>>>>>>>>framework/commons
>>>>>>>>>then like in many of the application they have specific
>
>  decorators
>
>>>>>>>>>that
>>>>>>>>>include the main-decorator.
>>>>>>>>>the problems is how to fill in the actions, etcetera
>>>>>>>>>
>>>>>>>>>Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>All the <include> does is grab some xml elements from the
>>
>>location
>>
>>>>>>>>>>described.  Theoretically, It doesn't even need to be from
>
>  the
>
>>same
>>
>>>>>>>>>>server, much less the same app (may have interesting
>>
>>possibilities
>>
>>>>>>>>>>BTW).  This is why I'm having such a hard time understanding
>
>  why
>
>>you
>>
>>>>>>>>>>are trying to attach context to it.
>>>>>>>>>>
>>>>>>>>>>----- Original Message ----
>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>To: [hidden email]
>>>>>>>>>>Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>I was going thru the trunk and noticed this in all the
>>
>>controllers
>>
>>>>>>>>>> <include
>>>>>>>>>>location="component://common/webcommon/WEB-INF/common-
>>
>>controller.xml"/>
>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>so there is a rule that says you can include a controller
>
>  not in
>
>>the
>>
>>>>>>>>>>same app.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Almost.
>>>>>>>>>>>when the included controller view calles a screen in the
>>
>>partymgr
>>
>>>>>>>>>>screen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>, and that screen calls for a parm that is web.xml. the
>
>  parm is
>
>>not
>>
>>>>>>>>>>>availible for the screen and so fails.
>>>>>>>>>>>
>>>>>>>>>>>At this time, the way I handle this is to put the parm in
>
>  my
>
>>>>>>>>>>>Web.xml.
>>>>>>>>>>>
>>>>>>>>>>>My suggestions was that if a call is made to a parm that
>
>  would
>
>>>>>>>>>>>be in
>>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>applications, in this case partymgr, web.xml, that widget
>
>  looks
>
>>up
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>web.xml for that application to get it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Okay, I've read through the thread.  In that case, I might
>>
>>suggest
>>
>>>>>>>>>>to take a step back and look at what the two functionalities
>
>  were
>
>>>>>>>>>>designed to accomplish.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>Creating the mainDecoratorLocation variable in the web.xml
>
>  was
>
>>>>>>>>>>designed for _screen reuse. the include element in the
>>>>>>>>>>controller.xml
>>>>>>>>>>file
>>>>>>>>>>was designed for request/response maintenance.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>With that in mind, you can include another controller in
>
>  your
>
>>>>>>>>>>>>custom
>>>>>>>>>>
>>>>>>>>>>application and then override the view with one that points
>
>  to
>
>>your
>>
>>>>>>>>>>application.   If you wish to then include a screen from
>
>  another
>
>>>>>>>>>>application you can use the <include-screen> element in the
>>
>>screen
>>
>>>>>>>>>>widget and
>>>>>>>>>>at the same time pass a parameters.mainDecoratorLocation to
>>>>>>>>>>override the
>>>>>>>>>>one gained from the web.xml context of the webapp being
>
>  used.
>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>It appears that what BJ is suggesting would make the
>
>  screen
>
>>being
>>
>>>>>>>>>>called from the ofbiz application nonreusable except as
>
>  decorated
>
>>>>>>>>>>as it
>>>>>>>>>>is in the ofbiz project which defeats the entire purpose of
>
>  the
>
>>>>>>>>>>mainDecoratorLocation variable.  Do I follow correctly?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>----- Original Message ----
>>>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>To: [hidden email]
>>>>>>>>>>>>Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>>>
>>>>>>>>>>>>Chris the discussion is about using the include in the
>>
>>controller.
>>
>>>>>>>>>>>>and that the current way of putting the locations of
>
>  parameters
>
>>>>>>>>>>>>used
>>>>>>>>>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the widgets for screen decorators is causing a problem
>>>>>>>>>>>>In a lot of apps the location is called out in the web.xml
>>>>>>>>>>>><context-param>
>>>>>>>>>>>><param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>
>

  <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>

>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>  <description>The location of the main-decorator screen
>
>  to use
>
>>>>>>>>>>for
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>this webapp; referred to as a context variable in screen
>
>  def
>
>>XML
>>
>>>>>>>>>>>>files.</description>
>>>>>>>>>>>></context-param>
>>>>>>>>>>>>
>>>>>>>>>>>>The suggeston is to take the location out to the web.xml
>
>  and
>
>>>>>>>>>>>>put in
>>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>widget like so.
>>>>>>>>>>>>
>>>>>>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>
>
>  location="component://party/widget/partymgr/CommonScreens.xml">
>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>I haven't been following the thread, but instead of
>
>  setting it
>
>>>>>>>>>>>>explicitly in the widgets section, you may prefer to
>
>  define it
>
>>in
>>
>>>>>>>>>>the actions
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>section...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>><action>
>>>>>>>>>>>>><set field="parameters.mainDecoratorLocation"
>>>>>>>>>>>>
>  value="component://party/widget/partymgr/CommonScreens.xml"/>
>
>>>>>>>>>>>>></action>
>>>>>>>>>>>>><widget>
>>>>>>>>>>>>><include-screen name="splitScreen"/>
>>>>>>>>>>>>></widget>
>>>>>>>>>>>>>...
>>>>>>>>>>>>><decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>
>>>>>>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>
>>>>>>>>>>>>><screen name="splitScreen">
>>>>>>>>>>>>>...
>>>>>>>>>>>>><widget>
>>>>>>>>>>>>>
>>>>>>>>>>>>></widget>
>>>>>>>>>>>>>...
>>>>>>>>>>>>>or something similar that it remains a variable so that
>
>  you
>
>>can
>>
>>>>>>>>>>later
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>split the widget section out to be it's own screen so that
>
>  it
>
>>can
>>
>>>>>>>>>>be
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>used with the decorator in another webapp.  I don't know
>
>  if the
>
>>>>>>>>>>screens
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>you're worried  about here are that complex.  This has
>
>  been a
>
>>>>>>>>>>better
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>pattern for me.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>----- Original Message ----
>>>>>>>>>>>>>From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>>To: [hidden email]
>>>>>>>>>>>>>Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>>>>>>>Subject: Re: Include of controllers
>>>>>>>>>>>>>
>>>>>>>>>>>>>Just want to make sure we are all on the same page
>>>>>>>>>>>>>in a widget screen
>>>>>>>>>>>>>             <decorator-screen
>
>  name="CommonPartyDecorator"
>
>>>>>>>>>>>>>location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>>
>>>>>>>>>>>>>parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>>>>>>
>>>>>>>>>>>>><context-param>
>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>>
>

  <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>

>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> <description>The location of the main-decorator screen
>
>  to use
>
>>>>>>>>>>for
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>this webapp; referred to as a context variable in screen
>
>  def
>
>>XML
>>
>>>>>>>>>>>>>files.</description>
>>>>>>>>>>>>></context-param>
>>>>>>>>>>>>>
>>>>>>>>>>>>>so to "fix"
>>>>>>>>>>>>>             <decorator-screen
>
>  name="CommonPartyDecorator"
>
>>location="component://party/widget/partymgr/CommonScreens.xml">
>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>Ok so the code that allows the context to be used in the
>>
>>web.xml
>>
>>>>>>>>>>is
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>being depreciated?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Nothing is being reversed. You have pointed out a
>
>  weakness
>
>>>>>>>>>>>>>>>in how
>>>>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>some of the party manager screens are set up (they
>
>  can't be
>
>>>>>>>>>>>>reused).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>I
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>have confirmed they have a problem. So submitting a
>
>  patch
>
>>FIXES
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>issue - it doesn't reverse anything.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I will not submit a patch for what I am proposing,
>
>  like a
>
>>>>>>>>>>>>>>>>lot of
>>>>>>>>>>>>
>>>>>>>>>>>>my
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>code, it stays in the applications I am doing.
>>>>>>>>>>>>>>>>and since someone else put effort into what is in
>
>  ofbiz now
>
>>>>>>>>>>>>>>>>I do not plan to put effort into reversing it.
>>>>>>>>>>>>>>>>:)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>As I mentioned before, I believe it would be
>
>  better/easier
>
>>to
>>
>>>>>>>>>>fix
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>party manager screens. Including web.xml files will
>
>  open
>
>>up a
>>
>>>>>>>>>>big
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>can of
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>worms.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>BJ Freeman wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Hans:
>>>>>>>>>>>>>>>>>>I did not put the CommonCommunicationEventDecorator
>>
>>location
>>
>>>>>>>>>>in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>context in web.xml
>>>>>>>>>>>>>>>>>>this was done by someone else and is a standard
>
>  through
>
>>>>>>>>>>>>>>>>>>ofbiz
>>>>>>>>>>
>>>>>>>>>>as
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>far as
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>i can tell.
>>>>>>>>>>>>>>>>>>I take the path of least resistance.
>>>>>>>>>>>>>>>>>>Since it is possible to put context in the web.xml
>
>  and
>
>>>>>>>>>>>>>>>>>>someone
>>>>>>>>>>>>>
>>>>>>>>>>>>>has
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>put a
>>>>>>>>>>>>>>>>>>lot of effort into refactoring ofbiz to this
>
>  standard, I
>
>>>>>>>>>>>>>>>>>>have
>>>>>>>>>>
>>>>>>>>>>no
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>intention of undoing it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>so my focus for my code will be to have the
>
>  web.xmlincluded
>
>>>>>>>>>>as
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>well,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>unless the powers to be say there is going to be a
>
>  change
>
>>in
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>best
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>practices.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Hi Bj,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>request (or provide a patch) that the
>>>>>>>>>>>>>>>>>>>CommonCommunicationEventDecorator
>>>>>>>>>>>>>>>>>>>is moved to the xml file as defined in the web.xml
>>>>>>>>>>>>>>>>>>>parameter.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Also
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>request that the 'location' parameter is defined in
>
>  the
>
>>>>>>>>>>screen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>you are
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>using.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Then you can use this screen in your own
>
>  application
>
>>using
>>
>>>>>>>>>>your
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>own
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>decorator.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>Regards,
>>>>>>>>>>>>>>>>>>>Hans
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman
>
>  wrote:
>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>I have a controller.xml
>>>>>>>>>>>>>>>>>>>>it has the include for the partymgr in it.
>>>>>>>>>>>>>>>>>>>>I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>>>>>>>I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>>>>>>>so I get to the find screen OK.
>>>>>>>>>>>>>>>>>>>>I have a few others in my web.xml as well.
>>>>>>>>>>>>>>>>>>>>so I can navigate.
>>>>>>>>>>>>>>>>>>>>however if you don't have these in your web.xml
>
>  that is
>
>>in
>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>same
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>directory as the controller.xml you are using
>>>>>>>>>>>>>>>>>>>>https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>>>>>>>then you get messages like this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>org.ofbiz.base.util.GeneralException: Error
>
>  rendering
>
>>>>>>>>>>>>>>>>>>>>screen
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>

  [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:

>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>java.lang.IllegalArgumentException: Could not find
>>
>>screen
>>
>>>>>>>>>>with
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>name
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same
>
>  file as
>
>>>>>>>>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>screen
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>>>>>>name [EditCommunicationEvent] (Could not find
>
>  screen
>
>>with
>>
>>>>>>>>>>name
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>[CommonCommunicationEventDecorator] in the same
>
>  file as
>
>>>>>>>>>>>>>>>>>>>>the
>>>>>>>>>>>>>
>>>>>>>>>>>>>screen
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>>>>>>>>name [EditCommunicationEvent])
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>BJ,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>Do you have any specific examples of what you're
>>>>>>>>>>>>>>>>>>>>describing?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>-Adrian
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:59
>
>  PM:
>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>sorry not a complete thougt
>>>>>>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>>>>>>and there is a commonscreen.xml defined in the
>
>  web.xmlof
>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>calling
>>>>>>>>>>>>>>>>>>>>>controller application it causes an error.
>>>>>>>>>>>>>>>>>>>>>so maybe puttting the application name before
>>>>>>>>>>
>>>>>>>>>>commonescreens
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>will
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>eliminate that.
>>>>>>>>>>>>>>>>>>>>>BJ Freeman sent the following on 11/5/2007 3:55
>
>  PM:
>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>>when you included another contorller
>>>>>>>>>>>>>>>>>>>>>>and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>another is that when the the other widget from
>
>  the
>
>>>>>>>>>>included
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>controller
>>>>>>>>>>>>>>>>>>>>>>calls for a context that is in the web.xml of
>
>  that
>
>>>>>>>>>>>>>application.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>it is not found.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>

[BJ Freeman]

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.


Chris Howe sent the following on 12/17/2007 2:01 PM:

> I suggested that as well and Scott echoed it. It doesn't seem to be satisfactory to BJ.  So we work at it.
>
> ----- Original Message ----
> From: Adrian Crum <[hidden email]>
> To: [hidden email]
> Sent: Monday, December 17, 2007 3:57:53 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> If all BJ wants to do is display an existing screen with its existing
>  main decorator, then he can
> just use the screen's URL.
>
> Chris Howe wrote:
>
>> Because he wants screens from the party component to be decorated
>  with the mainDecoratorLocation defined in
>  party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent decorated with the
>  mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml
>> Adrian's solution doesn't appear to solve this problem for BJ. (I had
>  misread the details of his explanation in saying that it had
>  previously).  BJ requires a custom servlet that will do something like the
>  following:
>> 1) process as normal until it begins to process the view
>> 2) place the <view-map>@page attribute into the context (split the
>  screen ${screen} from the location${location})
>> 3) render the following screen
>>
>> <screen name="customScreen">
>>     <section>
>>       <actions>
>>            <!-- Script or service or to define mainDecoratorLocation
>  based on value of ${location}
>>            ie if location=component://party/.... set
>  parameters.mainDecoratorLocation = component://party/widget/party/CommonScreens.xml
>>           -->
>>       </actions>
>>       <widget>
>>            <include-screen name="${screen}" location="${location}"/>
>>       </widget>
>>     </section>
>> </screen>
>>
>>
>>
>> ----- Original Message ----
>> From: Scott Gray <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, December 17, 2007 3:27:53 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> Why couldn't you supply your own custom mainDecorator?  What do the
>>  base
>> mainDecorators provide that you can't in your custom app?
>>
>> Scott
>>
>> On 18/12/2007, BJ Freeman <[hidden email]> wrote:
>>
>>> Based on this, I can never see how even if I called from a custom app
>>> different screens in different apps how one main-decorator
>>> so I am not sure how this feature would work at all.
>>>
>>> Hence my original suggestion that is apps main-decorator be declared
>>  as
>>
>>> application-mainDecoratorLocation
>>> this way I could include each apps mainDecoratorLocation and not have
>>  to
>>
>>> worry
>>>
>>>
>>> BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>>
>>>> I have a menu, no screens, that calls ListPartyCommEvents
>>>> this goes to the party controller to resolve.
>>>> the party controller uses it view for ListPartyCommEvents
>>>> It can not read the party web.xml so will error even with your
>>  changes.
>>
>>>> so lets say i put in a mainDecoratorLocation in my web xml and
>>  define it
>>
>>>> like the one in the party commonscreens.xml
>>>>
>>>> so far so good.
>>>>
>>>> Now I call a screen in say Product. except the
>>  mainDecoratorLocation for
>>
>>>> it has a different main-decorator. so all the requirements are not
>>>> defined in the party main-Decorator I have ported over.
>>>>
>>>> we still have a problem since all the apps main-decorators are not
>>  the
>>
>>> same.
>>>
>>>> now if the main-decorators were all the same then I could use one
>>>> location in any of the apps and everything would be ok
>>>>
>>>>
>>>>
>>>> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>>>
>>>>> 1. Move the CommonCommunicationEventDecorator screen to the
>>>>> communicationsscreens.xml file.
>>>>> 2. Change all
>>>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>
>>>>> to
>>>>>
>>>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>>>> location="${parameters.communicationEventDecoratorLocation}">
>>>>>
>>>>> Since parameters.communicationEventDecoratorLocation isn't defined
>>>>> anywhere, the location will evaluate to the current file:
>>>>> communicationsscreens.xml. All communication screens still work
>>  the
>>
>>> same
>>>
>>>>> in Party Manager, but now you can reuse those screens in another
>>  app.
>>
>>>>> When you use one of the communication screens in your custom app
>>  (via
>>
>>>>> included controller.xml file or otherwise) the
>>>>> parameters.communicationEventDecoratorLocation still isn't defined
>>>>> anywhere, so it still evaluates to the current file:
>>>>> communicationsscreens.xml. The communication screen and the
>>>>> CommonCommunicationEventDecorator will both appear - decorated
>>  with
>>
>>> your
>>>
>>>>> custom app's main decorator.
>>>>>
>>>>> (Optional) If someone didn't like the
>>> CommonCommunicationEventDecorator,
>>>
>>>>> then they could design their own and specify its location in
>>>>> parameters.communicationEventDecoratorLocation.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> BJ Freeman wrote:
>>>>>
>>>>>
>>>>>> Ok here is a real situation:
>>>>>> take the party/widgets/partymgr/commicationsscreens.xml
>>>>>> <decorator-screen name="CommonCommunicationEventDecorator"
>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>> which is the CommonSreens.xml
>>>>>> which has
>>>>>> <decorator-screen name="main-decorator"
>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>
>>>>>> the main-decorator has
>>>>>>                <include-screen name="GlobalDecorator"
>>>>>> location="component://common/widget/CommonScreens.xml"/>
>>>>>>
>>>>>>
>>>>>> how would the be with your example
>>>>>>
>>>>>>
>>>>>>
>>>>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>>>>
>>>>>>
>>>>>>> BJ,
>>>>>>>
>>>>>>> Go ahead and create one. I will work on it when I have time.
>>>>>>>
>>>>>>> To be sure we're all on the same page, the problem exists when
>>> screens
>>>
>>>>>>> are nested as follows:
>>>>>>>
>>>>>>> <screen name="GlobalDecorator">
>>>>>>> <screen name="main-decorator">
>>>>>>>   <screen name="sub-decorator">
>>>>>>>     <screen name="actual-content">
>>>>>>>       ...
>>>>>>>     </screen>
>>>>>>>   </screen>
>>>>>>> </screen>
>>>>>>> </screen>
>>>>>>>
>>>>>>> and the location of the sub-decorator screen is defined as
>>>>>>> ${parameters.mainDecoratorLocation}. When a custom app tries to
>>  reuse
>>
>>>>>>> the actual-content screen, errors are generated because
>>>>>>> <decorator-screen name="sub-decorator"
>>>>>>> location="${parameters.mainDecoratorLocation}"> evaluates to the
>>> custom
>>>
>>>>>>> app's main decorator xml file, and the sub-decorator screen
>>  doesn't
>>
>>>>>>> exist there.
>>>>>>>
>>>>>>> The solution to the problem is to avoid using
>>>>>>> ${parameters.mainDecoratorLocation} as a location for
>>  sub-decorators
>>
>>> and
>>>
>>>>>>> either have no location specified or use a different parameter
>>  for
>>
>>> the
>>>
>>>>>>> sub-decorator's location - like ${subDecoratorLocation}.
>>>>>>>
>>>>>>> A good example of this approach is in AgreementScreens.xml in
>>  the
>>
>>>>>>> Accounting component. All of the Agreement screens share a
>>  common
>>
>>>>>>> sub-decorator (CommonAgreementDecorator) - and that decorator's
>>> location
>>>
>>>>>>> is specified as ${parameters.agreementDecoratorLocation}. The
>>>>>>> agreementDecoratorLocation parameter isn't defined anywhere, so
>>  the
>>
>>>>>>> location= expression evaluates to an empty String - which causes
>>  the
>>
>>>>>>> screen widget view handler to look for CommonAgreementDecorator
>>  in
>>
>>> the
>>>
>>>>>>> existing file.
>>>>>>>
>>>>>>> A custom app that reuses one of the Agreement screens will only
>>  need
>>
>>> to
>>>
>>>>>>> specify the mainDecoratorLocation parameter. Since no
>>>>>>> agreementDecoratorLocation parameter is defined in the custom
>>  app,
>>
>>> the
>>>
>>>>>>> sub-decorator in AgreementScreens.xml is used (same as above).
>>  If a
>>
>>>>>>> custom app wanted to have a custom sub-decorator, then it can
>>  specify
>>
>>>>>>> that decorator's location in the agreementDecoratorLocation
>>> parameter.
>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> BJ Freeman wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I agree, it is not a controller or web.xml issue. However it is
>>  when
>>
>>> it
>>>
>>>>>>>> shows up.
>>>>>>>> I will change them as I come along also.
>>>>>>>> thanks, that is all I wanted to know.
>>>>>>>> do you want to create a jira so I can submit changes?
>>>>>>>>
>>>>>>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> As I mentioned before, the problem is with the coding style on
>>  some
>>
>>>>>>>>> screens, not with the controller or web.xml files. I recently
>>> changed
>>>
>>>>>>>>> some of the accounting screens to correct this error.
>>>>>>>>>
>>>>>>>>> -Adrian
>>>>>>>>>
>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I am not really, trying to attach the context as a whole.
>>>>>>>>>> only trying to get the mainDecoratorLocation
>>>>>>>>>> which is stored as a context in web.xml.
>>>>>>>>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>>>>>>>>> then all applications I call thru my controller, or the
>>  included
>>
>>>>>>>>>> ones,
>>>>>>>>>> will use my mainDecoratorLocation full path.
>>>>>>>>>> Maybe the solution is to put the main-decorator for all apps
>>  in
>>
>>> the
>>>
>>>>>>>>>> framework/commons
>>>>>>>>>> then like in many of the application they have specific
>>  decorators
>>
>>>>>>>>>> that
>>>>>>>>>> include the main-decorator.
>>>>>>>>>> the problems is how to fill in the actions, etcetera
>>>>>>>>>>
>>>>>>>>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> All the <include> does is grab some xml elements from the
>>> location
>>>
>>>>>>>>>>> described.  Theoretically, It doesn't even need to be from
>>  the
>>
>>> same
>>>
>>>>>>>>>>> server, much less the same app (may have interesting
>>> possibilities
>>>
>>>>>>>>>>> BTW).  This is why I'm having such a hard time understanding
>>  why
>>
>>> you
>>>
>>>>>>>>>>> are trying to attach context to it.
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>> From: BJ Freeman <[hidden email]>
>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>> Sent: Saturday, December 15, 2007 12:19:27 PM
>>>>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I was going thru the trunk and noticed this in all the
>>> controllers
>>>
>>>>>>>>>>> <include
>>>>>>>>>>> location="component://common/webcommon/WEB-INF/common-
>>> controller.xml"/>
>>>
>>>>>>>>>>>
>>>>>>>>>>> so there is a rule that says you can include a controller
>>  not in
>>
>>> the
>>>
>>>>>>>>>>> same app.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Almost.
>>>>>>>>>>>> when the included controller view calles a screen in the
>>> partymgr
>>>
>>>>>>>>>>> screen
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> , and that screen calls for a parm that is web.xml. the
>>  parm is
>>
>>> not
>>>
>>>>>>>>>>>> availible for the screen and so fails.
>>>>>>>>>>>>
>>>>>>>>>>>> At this time, the way I handle this is to put the parm in
>>  my
>>
>>>>>>>>>>>> Web.xml.
>>>>>>>>>>>>
>>>>>>>>>>>> My suggestions was that if a call is made to a parm that
>>  would
>>
>>>>>>>>>>>> be in
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> applications, in this case partymgr, web.xml, that widget
>>  looks
>>
>>> up
>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> web.xml for that application to get it.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris Howe sent the following on 11/10/2007 2:23 PM:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Okay, I've read through the thread.  In that case, I might
>>> suggest
>>>
>>>>>>>>>>> to take a step back and look at what the two functionalities
>>  were
>>
>>>>>>>>>>> designed to accomplish.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Creating the mainDecoratorLocation variable in the web.xml
>>  was
>>
>>>>>>>>>>> designed for _screen reuse. the include element in the
>>>>>>>>>>> controller.xml
>>>>>>>>>>> file
>>>>>>>>>>> was designed for request/response maintenance.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> With that in mind, you can include another controller in
>>  your
>>
>>>>>>>>>>>>> custom
>>>>>>>>>>> application and then override the view with one that points
>>  to
>>
>>> your
>>>
>>>>>>>>>>> application.   If you wish to then include a screen from
>>  another
>>
>>>>>>>>>>> application you can use the <include-screen> element in the
>>> screen
>>>
>>>>>>>>>>> widget and
>>>>>>>>>>> at the same time pass a parameters.mainDecoratorLocation to
>>>>>>>>>>> override the
>>>>>>>>>>> one gained from the web.xml context of the webapp being
>>  used.
>>
>>>>>>>>>>>
>>>>>>>>>>>>> It appears that what BJ is suggesting would make the
>>  screen
>>
>>> being
>>>
>>>>>>>>>>> called from the ofbiz application nonreusable except as
>>  decorated
>>
>>>>>>>>>>> as it
>>>>>>>>>>> is in the ofbiz project which defeats the entire purpose of
>>  the
>>
>>>>>>>>>>> mainDecoratorLocation variable.  Do I follow correctly?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>>>> From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>>>> Sent: Saturday, November 10, 2007 2:12:12 PM
>>>>>>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris the discussion is about using the include in the
>>> controller.
>>>
>>>>>>>>>>>>> and that the current way of putting the locations of
>>  parameters
>>
>>>>>>>>>>>>> used
>>>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> the widgets for screen decorators is causing a problem
>>>>>>>>>>>>> In a lot of apps the location is called out in the web.xml
>>>>>>>>>>>>> <context-param>
>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>>
>   <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>  <description>The location of the main-decorator screen
>>  to use
>>
>>>>>>>>>>> for
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> this webapp; referred to as a context variable in screen
>>  def
>>
>>> XML
>>>
>>>>>>>>>>>>> files.</description>
>>>>>>>>>>>>> </context-param>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The suggeston is to take the location out to the web.xml
>>  and
>>
>>>>>>>>>>>>> put in
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> widget like so.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>>
>>  location="component://party/widget/partymgr/CommonScreens.xml">
>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris Howe sent the following on 11/9/2007 9:14 PM:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I haven't been following the thread, but instead of
>>  setting it
>>
>>>>>>>>>>>>> explicitly in the widgets section, you may prefer to
>>  define it
>>
>>> in
>>>
>>>>>>>>>>> the actions
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> section...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <action>
>>>>>>>>>>>>>> <set field="parameters.mainDecoratorLocation"
>>  value="component://party/widget/partymgr/CommonScreens.xml"/>
>>
>>>>>>>>>>>>>> </action>
>>>>>>>>>>>>>> <widget>
>>>>>>>>>>>>>> <include-screen name="splitScreen"/>
>>>>>>>>>>>>>> </widget>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> <decorator-screen name="CommonPartyDecorator"
>>>>>>>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <screen name="splitScreen">
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> <widget>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> </widget>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>> or something similar that it remains a variable so that
>>  you
>>
>>> can
>>>
>>>>>>>>>>> later
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> split the widget section out to be it's own screen so that
>>  it
>>
>>> can
>>>
>>>>>>>>>>> be
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> used with the decorator in another webapp.  I don't know
>>  if the
>>
>>>>>>>>>>> screens
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> you're worried  about here are that complex.  This has
>>  been a
>>
>>>>>>>>>>> better
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> pattern for me.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>>>>> From: BJ Freeman <[hidden email]>
>>>>>>>>>>>>>> To: [hidden email]
>>>>>>>>>>>>>> Sent: Friday, November 9, 2007 9:57:00 PM
>>>>>>>>>>>>>> Subject: Re: Include of controllers
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just want to make sure we are all on the same page
>>>>>>>>>>>>>> in a widget screen
>>>>>>>>>>>>>>             <decorator-screen
>>  name="CommonPartyDecorator"
>>
>>>>>>>>>>>>>> location="${parameters.mainDecoratorLocation}">
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> parameters.mainDecoratorLocation is in the Web.xml
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <context-param>
>>>>>>>>>>>>>> <param-name>mainDecoratorLocation</param-name>
>>>>>>>>>>>>>>
>   <param-value>component://party/widget/partymgr/CommonScreens.xml</param-value>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> <description>The location of the main-decorator screen
>>  to use
>>
>>>>>>>>>>> for
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> this webapp; referred to as a context variable in screen
>>  def
>>
>>> XML
>>>
>>>>>>>>>>>>>> files.</description>
>>>>>>>>>>>>>> </context-param>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> so to "fix"
>>>>>>>>>>>>>>             <decorator-screen
>>  name="CommonPartyDecorator"
>>
>>> location="component://party/widget/partymgr/CommonScreens.xml">
>>>
>>>>>>>>>>>>>> BJ Freeman sent the following on 11/9/2007 5:17 PM:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok so the code that allows the context to be used in the
>>> web.xml
>>>
>>>>>>>>>>> is
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> being depreciated?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 5:11 PM:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nothing is being reversed. You have pointed out a
>>  weakness
>>
>>>>>>>>>>>>>>>> in how
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> some of the party manager screens are set up (they
>>  can't be
>>
>>>>>>>>>>>>> reused).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> have confirmed they have a problem. So submitting a
>>  patch
>>
>>> FIXES
>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>> issue - it doesn't reverse anything.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I will not submit a patch for what I am proposing,
>>  like a
>>
>>>>>>>>>>>>>>>>> lot of
>>>>>>>>>>>>> my
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> code, it stays in the applications I am doing.
>>>>>>>>>>>>>>>>> and since someone else put effort into what is in
>>  ofbiz now
>>
>>>>>>>>>>>>>>>>> I do not plan to put effort into reversing it.
>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Adrian Crum sent the following on 11/9/2007 4:57 PM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As I mentioned before, I believe it would be
>>  better/easier
>>
>>> to
>>>
>>>>>>>>>>> fix
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> party manager screens. Including web.xml files will
>>  open
>>
>>> up a
>>>
>>>>>>>>>>> big
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> can of
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> worms.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hans:
>>>>>>>>>>>>>>>>>>> I did not put the CommonCommunicationEventDecorator
>>> location
>>>
>>>>>>>>>>> in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> context in web.xml
>>>>>>>>>>>>>>>>>>> this was done by someone else and is a standard
>>  through
>>
>>>>>>>>>>>>>>>>>>> ofbiz
>>>>>>>>>>> as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> far as
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> i can tell.
>>>>>>>>>>>>>>>>>>> I take the path of least resistance.
>>>>>>>>>>>>>>>>>>> Since it is possible to put context in the web.xml
>>  and
>>
>>>>>>>>>>>>>>>>>>> someone
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> put a
>>>>>>>>>>>>>>>>>>> lot of effort into refactoring ofbiz to this
>>  standard, I
>>
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>> no
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> intention of undoing it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> so my focus for my code will be to have the
>>  web.xmlincluded
>>
>>>>>>>>>>> as
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> well,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> unless the powers to be say there is going to be a
>>  change
>>
>>> in
>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> practices.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hans Bakker sent the following on 11/7/2007 5:47 PM:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Bj,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> request (or provide a patch) that the
>>>>>>>>>>>>>>>>>>>> CommonCommunicationEventDecorator
>>>>>>>>>>>>>>>>>>>> is moved to the xml file as defined in the web.xml
>>>>>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>> Also
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> request that the 'location' parameter is defined in
>>  the
>>
>>>>>>>>>>> screen
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> you are
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> using.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then you can use this screen in your own
>>  application
>>
>>> using
>>>
>>>>>>>>>>> your
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> decorator.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Hans
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Wed, 2007-11-07 at 13:42 -0800, BJ Freeman
>>  wrote:
>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have a controller.xml
>>>>>>>>>>>>>>>>>>>>> it has the include for the partymgr in it.
>>>>>>>>>>>>>>>>>>>>> I have a menu widget that calls the partmgr
>>>>>>>>>>>>>>>>>>>>> I have the PartymgrDecoratorLocation in my web.xml
>>>>>>>>>>>>>>>>>>>>> so I get to the find screen OK.
>>>>>>>>>>>>>>>>>>>>> I have a few others in my web.xml as well.
>>>>>>>>>>>>>>>>>>>>> so I can navigate.
>>>>>>>>>>>>>>>>>>>>> however if you don't have these in your web.xml
>>  that is
>>
>>> in
>>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> directory as the controller.xml you are using
>>>>>>>>>>>>>>>>>>>>> https://localhost:8443/myapp/control/partymgr
>>>>>>>>>>>>>>>>>>>>> then you get messages like this.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> org.ofbiz.base.util.GeneralException: Error
>>  rendering
>>
>>>>>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>>>>>>
>   [component://party/widget/partymgr/CommunicationScreens.xml#EditCommunicationEvent]:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> java.lang.IllegalArgumentException: Could not find
>>> screen
>>>
>>>>>>>>>>> with
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same
>>  file as
>>
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> name [EditCommunicationEvent] (Could not find
>>  screen
>>
>>> with
>>>
>>>>>>>>>>> name
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [CommonCommunicationEventDecorator] in the same
>>  file as
>>
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> name [EditCommunicationEvent])
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> BJ,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Do you have any specific examples of what you're
>>>>>>>>>>>>>>>>>>>>> describing?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -Adrian
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:59
>>  PM:
>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> sorry not a complete thougt
>>>>>>>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>>>>>>>> and there is a commonscreen.xml defined in the
>>  web.xmlof
>>
>>>>>>>>>>> the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>> controller application it causes an error.
>>>>>>>>>>>>>>>>>>>>>> so maybe puttting the application name before
>>>>>>>>>>> commonescreens
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> eliminate that.
>>>>>>>>>>>>>>>>>>>>>> BJ Freeman sent the following on 11/5/2007 3:55
>>  PM:
>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This is not a real bug.
>>>>>>>>>>>>>>>>>>>>>>> when you included another contorller
>>>>>>>>>>>>>>>>>>>>>>> and it has a commonscreen.xml
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> another is that when the the other widget from
>>  the
>>
>>>>>>>>>>> included
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> controller
>>>>>>>>>>>>>>>>>>>>>>> calls for a context that is in the web.xml of
>>  that
>>
>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> it is not found.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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.

[BJ Freeman]

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 <[hidden email]>
> To: [hidden email]
> 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.
>
>
>
>
>
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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.
>
>
>
>
>
>
>
>

[BJ Freeman]

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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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.
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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.
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[BJ Freeman]

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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[cjhowe]

Make your own decorator

----- Original Message ----
From: BJ Freeman <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[BJ Freeman]

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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[BJ Freeman]

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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>

[cjhowe]

be sure to define the mainDecoratorLocation in the web.xml as component://myapp/widget/CommonScreens.xml

From there the only app specific stuff is the whether it's including leftbar/rightbar/etc.  You will need to define those basic ones as well.

----- Original Message ----
From: BJ Freeman <[hidden email]>
To: [hidden email]
Sent: Monday, December 17, 2007 5:59:58 PM
Subject: Re: mainDecoratorLocation was Include of controllers


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 <[hidden email]>
> To: [hidden email]
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[Adrian Crum]

BJ Freeman wrote:
> 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

Most main-decorators don't have app-specific information in them. They pretty much all set up the
same context variables and such. You will need to add <action> elements for each of the app's UI
labels properties files and any other app specific things (like the party manager java script and
stylesheet mentioned earlier).

So, there is some effort involved and a few additional lines of code in your custom app
main-decorator, but the tradeoff is not having to re-design screens.

-Adrian

[Adrian Crum]

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 <[hidden email]>
>>>To: [hidden email]
>>>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 <[hidden email]>
>>>>To: [hidden email]
>>>>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 <[hidden email]>
>>>>>To: [hidden email]
>>>>>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 <[hidden email]>
>>>>>>To: [hidden email]
>>>>>>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.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

[cjhowe]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>

[BJ Freeman]

Chris Howe sent the following on 12/17/2007 4:09 PM:
> be sure to define the mainDecoratorLocation in the web.xml as component://myapp/widget/CommonScreens.xml
yes
>
>>From there the only app specific stuff is the whether it's including leftbar/rightbar/etc.  You will need to define those basic ones as well.
you have not looked at the current main-decoroators
here is one from party
1) defines Java scripts to use
2) defines <set field="activeApp" value="partymgr" global="true"/>
So I can only define one <set field="activeApp" value="setup"
global="true"/>
so when partymgr looks for the active app it will go to setup instead of
patrymgr.
This mean I have a lot of overhead in maintainence instead of just using
the partymgr as is.

or like
<set field="appheaderTemplate"
value="component://order/webapp/ordermgr/includes/appheader.ftl"
global="true"/>

>
> ----- Original Message ----
> From: BJ Freeman <[hidden email]>
> To: [hidden email]
> Sent: Monday, December 17, 2007 5:59:58 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> 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 <[hidden email]>
>> To: [hidden email]
>> 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 <[hidden email]>
>>> To: [hidden email]
>>> 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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>

[BJ Freeman]

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 <[hidden email]>
>>>> To: [hidden email]
>>>> 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 <[hidden email]>
>>>>> To: [hidden email]
>>>>> 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 <[hidden email]>
>>>>>> To: [hidden email]
>>>>>> 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 <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>