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.xml included
> 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.xml of
> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
>
