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.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
