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 <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> 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 <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>>>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>>>>>>> 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 <[EMAIL PROTECTED]>
>>>>>>>>>>>>>> To: dev@ofbiz.apache.org
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
>
>
>
>
