to clarify
app-main-decorator means appname-main-decorator
BJ Freeman sent the following on 11/23/2007 4:07 AM:
> I think the focus got lost in my explaining what i am doing.
> 1) the main-decorator defines a path in that application to where it is.
> 2) the main-decorator is used in the local apps widgets and that may be
> where the problem is. Since from this conversation is sounds like it was
> meant to be used for the
> component://common/widget/CommonScreens.xml#GlobalDecorator
> 3)So if I am correct then the main-decorator is not following the best
> practices in each app by being used by the apps widgets.
> 4)the uses in the app sould have a app-main-decorator that the
> application widget use.
> 5)if this was implemented, then the problem goes away becuase I can
> include the app-main-decorator in my web.xml.
>
>
>
> Scott Gray sent the following on 11/22/2007 10:22 PM:
>> This whole scenario makes no sense to me and I really can't see any benefits
>> to be had from pursuing it.
>>
>> Regards
>> Scott
>>
>> On 23/11/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>>> Oh yeah, that's right! Good catch.
>>>
>>> BJ, you'll have to change
>>> component://common/widget/CommonScreens.xml#GlobalDecorator a bit.
>>>
>>> Add a higher-priority overriding variable say "forceAppHeaderTemplate". If
>>> that parameter is
>>> present, "appHeaderTemplate" will be ignored. Just FYI, the
>>> "appHeaderTemplate" deals with the
>>> horizontal menu at the top of the screen. I imagine you would want your
>>> own menu items there.
>>>
>>> All these fixes will mean you won't have to change any screen widgets in
>>> order to bundle them into
>>> your special giant webapp.
>>>
>>> Is there anyone else doing this giant webapp pattern? I've only ever been
>>> asked to extend an
>>> original webapp and mount it on a different request path, at most. The
>>> problem that BJ encountners
>>> should only come when we combine 2 or more original webapps together.
>>>
>>> Let me know how it goes!
>>>
>>> Jonathon
>>>
>>> Scott Gray wrote:
>>>> How on earth could this work? Each main-decorator specifies an
>>>> appheaderTemplate which displays the navigation menu for that
>>> application,
>>>> how is the user navigating between the various applications that you
>>> have
>>>> bundled into one? Have you replaced/altered the GlobalDecorator to
>>> display
>>>> the "sub" applications?
>>>>
>>>> I really don't think your following best practices here and that is
>>> exactly
>>>> why you are having troubles. If you want to have a single component in
>>>> which to maintain your customizations you should follow the ecomclone
>>>> example and put a webapp entry for each base app in your
>>> ofbiz-component.xml
>>>> .
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 23/11/2007, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
>>>>> BJ,
>>>>>
>>>>> Understood. As I had suspected, you wanted a single look, single
>>>>> application, one tab.
>>>>>
>>>>>> I am not moving any code from the trunk or ver 4.0 into my app.
>>>>> Yes, you're doing great extending OFBiz cleanly.
>>>>>
>>>>>> If I changes something like say the order statuses then the code I
>>>>> changed,
>>>>>> as well as the screens are in my application.
>>>>> Sounds right. Extension codes are cleanly separated from original OFBiz
>>>>> codes.
>>>>>
>>>>>> to get back to the original problem I need a way to declare the
>>>>>> mainDecoratorLocation that has different paths so it can be read when
>>>>> the
>>>>>> controller for that component is read.
>>>>> As mentioned, you need to change ConfigXMLReader, possibly
>>> ControlServlet
>>>>> and RequestManager. Just
>>>>> add a new top-level (below <site-conf>) element called
>>>>> "<main-decorator-loc>". The ConfigXMLReader
>>>>> will prepend the webapp name to "mainDecoratorLocation", so you get
>>>>> something like
>>>>> "ordermgr:mainDecoratorLocation".
>>>>>
>>>>> Or easier, simply change those same classes to read the web.xml file
>>>>> instead. Read the web.xml
>>>>> file in the same folder as the included (<include>) controller.xml .
>>>>>
>>>>>> then I will let what ever reads it preappend the component name to
>>>>>> mainDecoratorLocation, and track it.
>>>>> You need to change ModelScreenWidget, and add some additional
>>> processing
>>>>> for attribute "location".
>>>>>
>>>>> Whenever ModelScreenWidget sees in attribute "location" a value of
>>>>> "${parameters.mainDecoratorLocation}", it will create a
>>>>> FlexibleStringExpander with string
>>>>> "${parameters.ordermgr:mainDecoratorLocation}" instead.
>>>>>
>>>>> I too love to cleanly organize code like this, rather than mess up
>>> OFBiz's
>>>>> internals. I wish you
>>>>> success in implementing this, which is easy enough. Hope you can get
>>> this
>>>>> into OFBiz SVN so I can
>>>>> have it too. :)
>>>>>
>>>>> Jonathon
>>>>> BJ Freeman wrote:
>>>>>> Just to clarify, I consider my app an overlay.
>>>>>> I am not moving any code from the trunk or ver 4.0 into my app.
>>>>>> for instance I am merging two ftl in Ordermgr.
>>>>>> I do create a widget but the ftl are till in ordermgr.
>>>>>> this saves a lot of re-integration when the trunk or relase base
>>>>> changes.
>>>>>> so client will see what ever the ordermgr controller serves up once
>>> the
>>>>>> client does an action.
>>>>>>
>>>>>> If I changes something like say the order statuses then the code I
>>>>>> changed, as well as the screens are in my application.
>>>>>>
>>>>>> to return to my menu, they click on the only tab visible, which is my
>>>>>> application tab.
>>>>>>
>>>>>> I do have Ecas and services in my app that extends ofbiz, but is
>>> unique
>>>>>> to Yahoo functions.
>>>>>>
>>>>>> so to upgrade from the release to the trunk, I just move my app into
>>> the
>>>>>> trunk copy I made and add the folder to the trunks component-load.xml
>>>>>>
>>>>>> to get back to the original problem I need a way to declare the
>>>>>> mainDecoratorLocation that has different paths so it can be read when
>>>>>> the controller for that component is read.
>>>>>> then I will let what ever reads it preappend the component name to
>>>>>> mainDecoratorLocation, and track it.
>>>>>>
>>>>>> so time to dig into the code.
>>>>>> :)
>>>>>>
>>>>>>
>>>>>> Jonathon -- Improov sent the following on 11/22/2007 3:22 AM:
>>>>>>> Your use case seems valid.
>>>>>>>
>>>>>>> In a nutshell, you're simply cloning a webapp, and then extending it
>>>>>>> with your own requests and features.
>>>>>>>
>>>>>>> That's great. It means you won't have to repeat the scores of request
>>>>>>> maps in the webapp you're cloning.
>>>>>>>
>>>>>>> That said, it's pretty scary to see 6 webapps rolled into 1 (your
>>>>> custom
>>>>>>> webapp, where you extend original OFBiz codes). Still, it's just a
>>>>>>> matter of splitting up those 6 webapps into 6 custom webapps,
>>> something
>>>>>>> you may do when you have time.
>>>>>>>
>>>>>>> I can see where having the mainDecoratorLocation parameter tied to
>>> the
>>>>>>> webapp (controller.xml) can be useful. But I find it hard to vote for
>>>>>>> making this extension to the OFBiz framework. You can simply extend
>>>>>>> webapp "workeffort" with "myworkeffort", and use the same
>>>>>>> mainDecoratorLocation that "workeffort" uses. In short, there's a
>>>>> simple
>>>>>>> and useful workaround now.
>>>>>>>
>>>>>>> Over time, it will be nice to be able to clone "workeffort" and let
>>> it
>>>>>>> use its own mainDecoratorLocation, while my extensions in
>>>>> "myworkeffort"
>>>>>>> use a different mainDecoratorLocation. No clash.
>>>>>>>
>>>>>>> I think I've worn myself out trying to explain technical issues in
>>>>>>> technical terms. Let me try an analogy. So, for the last time...
>>>>>>>
>>>>>>> Customer: "I want a hamburger."
>>>>>>>
>>>>>>> Cashier: "What's the code to activate my POS machine?"
>>>>>>>
>>>>>>> Customer: "I don't know?"
>>>>>>>
>>>>>>> Cashier: "Sorry, you need to know, or no hamburger for you."
>>>>>>>
>>>>>>> Customer: "Don't you know?"
>>>>>>>
>>>>>>> Cashier: "I know it for that other POS machine, not this one. You're
>>>>>>> ordering a hamburger from this one, so I can't serve you unless you
>>> got
>>>>>>> the code!"
>>>>>>>
>>>>>>> Customer: "I want to talk to your manager."
>>>>>>>
>>>>>>> Cashier: "Alright. He'll probably ask you write some codes to read
>>> the
>>>>>>> web.xml file in that other POS machine and retrieve the code
>>>>>>> (mainDecoratorLocation) there, so be prepared."
>>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>> BJ Freeman wrote:
>>>>>>>> I have some screens I handle differently.
>>>>>>>> I have kept from going crazy by calling the ones and let the
>>>>> controller
>>>>>>>> in that app handle it.
>>>>>>>> I have not had any problems so far, except for mainDecoratorLocation
>>>>>>>>
>>>>>>>> and from what I am reading it should not be where it is to follow
>>> best
>>>>>>>> practices.
>>>>>>>>
>>>>>>>> question is where to put it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris Howe sent the following on 11/22/2007 12:10 AM:
>>>>>>>>> Why are you opposed to running 6 separate webapps under a
>>> component?
>>>>>>>>> mycomponent/webapp
>>>>>>>>> /myworkeffort
>>>>>>>>> /mypartymgr
>>>>>>>>> /mymarketing
>>>>>>>>> /myordermgr
>>>>>>>>> /myaccounting
>>>>>>>>>
>>>>>>>>> /myyahoo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can almost guarantee you'll drive yourself insane with
>>> request-maps
>>>>>>>>> and view-maps overriding each other and giving unexpected results.
>>>>>>>>>
>>>>>>>>> ----- Original Message ----
>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>>> To: [email protected]
>>>>>>>>> Sent: Thursday, November 22, 2007 1:58:37 AM
>>>>>>>>> Subject: Re: mainDecoratorLocation change to
>>>>>>>>> [applicationname]mainDecoratorLocation
>>>>>>>>>
>>>>>>>>> my controller has
>>>>>>>>>
>>>>>>>>> <!-- request handler for workeffort specific calls -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://workeffort/webapp/workeffort/WEB-INF/controller.xml"/>
>>>>>>>>> <!-- request handler for partymgr specific calls -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://party/webapp/partymgr/WEB-INF/controller.xml"/>
>>>>>>>>> <!-- request handler for marketing specific calls -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://marketing/webapp/marketing/WEB-INF/controller.xml"/>
>>>>>>>>> <!-- request handler for ordermgr specific calls -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://order/webapp/ordermgr/WEB-INF/controller.xml"/>
>>>>>>>>> <!-- request handler for accounting specific calls -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://accounting/webapp/accounting/WEB-INF/controller.xml"/>
>>>>>>>>> <!-- request handler for yahoo specific calls note this should
>>> be
>>>>>>>>> the last one loaded -->
>>>>>>>>> <include
>>>>>>>>>
>>> location="component://yahoo/webapp/yahoo/WEB-INF/businessesnetworcontroller.xml"/>
>>>>>>>>>
>>>>>>>>> the last one is mine.
>>>>>>>>> I have a menu that has a target of
>>>>>>>>> <menu-item name="partymgr"
>>>>>>>>> title="${uiLabelMap.YahooPatrymgr}"><link
>>>>>>>>> target="partymgr"/></menu-item>
>>>>>>>>>
>>>>>>>>> and in my controller I have
>>>>>>>>> <view-map name="partymgr" type="screen"
>>>>>>>>>
>>> page="component://party/widget/partymgr/PartyScreens.xml#findparty"/>
>>>>>>>>> now if I don't have a mainDecoratorLocation defined in my web.xmlfor
>>>>>>>>> <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 screen for PartyScreens complains it can not find it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris Howe sent the following on 11/21/2007 10:16 PM:
>>>>>>>>>> Making the variable _name webapp specific would break the entire
>>>>>>>>> point of the variable.
>>>>>>>>>> The variable is webapp specific (meaning it's defined by the
>>>>> webapp),
>>>>>>>>> but the variable _name is not. There are no
>>>>>>>>> partyMainDecoratorLocation variables, only mainDecoratorLocation.
>>>>>>>>>> BJ, would it be possible for you to explain the webapp your
>>>>>>>>> developing. Off the top of my head, I'm unable to picture a
>>>>>>>>> scenario where
>>>>>>>>> wanting to maintain the decorator for two web applications is
>>>>>>>>> beneficial
>>>>>>>>> and would keep one sane. The only scenario that I can think of
>>> that
>>>>>>>>> even comes close is because of two different conventions being
>>> used
>>>>>>>>> in the
>>>>>>>>> screens of different components.
>>>>>>>>>> ----- Original Message ----
>>>>>>>>>> From: Jonathon -- Improov <[EMAIL PROTECTED]>
>>>>>>>>>> To: [email protected]
>>>>>>>>>> Sent: Thursday, November 22, 2007 12:03:18 AM
>>>>>>>>>> Subject: Re: mainDecoratorLocation change to
>>>>>>>>> [applicationname]mainDecoratorLocation
>>>>>>>>>> > Making the variable name webapp specific breaks the entire
>>> point
>>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>> > variable.
>>>>>>>>>>
>>>>>>>>>> The way the screen widgets are written now, the parameter
>>>>>>>>>> "mainDecoratorLocation" is already webapp-specific.
>>>>>>>>>>
>>>>>>>>>> The key question is where we want to tie mainDecoratorLocation to.
>>>>> If
>>>>>>>>>> it is specific to webapps, we tie it to controller.xml, so that
>>>>>>>>>> views defined in a webapp will
>>>>>>>>>> always use the decorator defined for that webapp. But if it is
>>>>>>>>>> specific to an OFBiz component,
>>>>>>>>>> then we tie it to a component config, like in
>>>>>>>>>> component://party/config/SomeConfigFile.xml
>>>>>>>>> .
>>>>>>>>>> Obviously, the screen widgets expect a correct value from
>>>>>>>>>> ${parameters.mainDecoratorLocation}. Where should this be
>>>>>>>>>> specified? If it is not webapp-specific, then
>>>>>>>>> does
>>>>>>>>>> that imply screen widgets look for a global OFBiz-wide
>>>>>>>>>> ${parameters.mainDecoratorLocation}
>>>>>>>>>> somewhere?
>>>>>>>>>>
>>>>>>>>>> If the variable name "mainDecoratorLocation" wasn't
>>> webapp-specific,
>>>>>>>>> we
>>>>>>>>>> wouldn't have this thread complaining about clashing or missing
>>>>>>>>>> "mainDecoratorLocation"
>>>>>>>>>> parameters when combining controller.xml(s) from multiple
>>> webapps.
>>>>>>>>>> > For example, do you determine the variable from the included
>>>>>>>>>> controller of
>>>>>>>>>> > the request-map or from the view-map. You would likely choose
>>>>> the
>>>>>>>>>> view. If
>>>>>>>>>> > it's the view, how do you determine when that component has
>>>>>>>>> multiple
>>>>>>>>>> webapp
>>>>>>>>>> > as in product, etc/.
>>>>>>>>>>
>>>>>>>>>> I would choose neither the request map nor the view map. I suggest
>>>>>>>>>> tying "mainDecoratorLocation" to controller.xml itself.
>>>>>>>>>>
>>>>>>>>>> If "mainDecoratorLocation" were view-specific, we would tie it to
>>> a
>>>>>>>>>> view map.
>>>>>>>>>>
>>>>>>>>>> As the screen widgets are written now, they are webapp-specific.
>>>>>>>>>>
>>>>>>>>>> Jonathon
>>>>>>>>>>
>>>>>>>>>> Chris Howe wrote:
>>>>>>>>>>> Hi Jonathon,
>>>>>>>>>>>
>>>>>>>>>>> Making the variable name webapp specific breaks the entire point
>>> of
>>>>>>>>>> the
>>>>>>>>>>> variable. I'm under the impression that most deployments of
>>> OFBiz
>>>>>>>>>> use very
>>>>>>>>>>> few of the applications as is, OOTB. Taking away the ability to
>>>>>>>>>> change
>>>>>>>>>>> the decoration of the application puts that much more burden on
>>>>>>>>>> custom
>>>>>>>>>>> applications to maintain a code base that is already maintained
>>> by
>>>>>>>>>> the
>>>>>>>>>>> community when all they want to do is extend and tweak subtle
>>>>> areas.
>>>>>>>>>>> The solution of further processing of the web.xml context-params
>>> in
>>>>>>>>>> order to fill the
>>>>>>>>>>> context starts to pull us away from the design of traditional web
>>>>>>>>>>> applications. This has the effect of steepening the learning
>>>>> curve.
>>>>>>>>>> In addition, there is too much ambiguity in deciding which
>>>>>>>>>> mainDecoratorLocation would be chosen that I think it really
>>> would
>>>>>>>>> be best to
>>>>>>>>>> determine it through a custom preprocessor so that one would end
>>> up
>>>>>>>>> with
>>>>>>>>>> the desired results. For example, do you determine the variable
>>>>>>>>> from
>>>>>>>>>> the included controller of the request-map or from the view-map.
>>>>>>>>> You
>>>>>>>>>> would likely choose the view. If it's the view, how do you
>>>>>>>>> determine
>>>>>>>>>> when that component has multiple webapp as in product, etc/.
>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>> From: Jonathon -- Improov <[EMAIL PROTECTED]>
>>>>>>>>>>> To: [email protected]
>>>>>>>>>>> Sent: Wednesday, November 21, 2007 10:56:14 PM
>>>>>>>>>>> Subject: Re: mainDecoratorLocation change to
>>>>>>>>>> [applicationname]mainDecoratorLocation
>>>>>>>>>>> I think BJ's method is fine. It's the only way to couple the
>>>>>>>>>>> webapp-specific parameter "mainDecorationLocation" to a
>>> particular
>>>>>>>>>>> webapp, and to decouple it
>>>>>>>>>>> from the single global servlet context (single to a webapp).
>>>>>>>>>>>
>>>>>>>>>>> Say a parent webapp includes the controller.xml of a child
>>> webapp,
>>>>>>>>> we
>>>>>>>>>>> use "parent" and "child" so it's easy for me to write here.
>>>>>>>>>>>
>>>>>>>>>>> When we <include> the child's controller.xml from the parent
>>>>> webapp,
>>>>>>>>>>> the servlet context is still the parent's, not a mix of 2
>>> webapps.
>>>>>>>>>>> There will be only one
>>>>>>>>>>> "mainDecoratorLocation" parameter for all the widgets listed in
>>>>>>>>>>> both controller.xml(s).
>>>>>>>>>>>
>>>>>>>>>>> When we need to process the views (or widgets) specified in the
>>>>>>>>>> child's
>>>>>>>>>>> controller.xml, we need to do something extra. Those views
>>> require
>>>>>>>>>>> a specific
>>>>>>>>>>> "mainDecoratorLocation" value in order to work, say
>>>>>>>>>>> "component://child/widget/MainDecorScreens.xml". The parent will
>>>>>>>>>>> need to play by those rules, and create "mainDecoratorLocation"
>>>>>>>>>>> with that expected value for the
>>>>>>>>>>> child's views to work. Specifically, I mean "for the child's
>>> views
>>>>>>>>>>> to work in the parent's
>>>>>>>>>>> servlet context".
>>>>>>>>>>>
>>>>>>>>>>> The problem comes when the parent also has its own
>>>>>>>>>>> "mainDecoratorLocation", say
>>>>>>>>>>> "component://parent/widget/MainDecorScreens.xml". Then there is a
>>>>>>>>>>> clash. Because the 2 webapps' widgets operate in a single
>>> servlet
>>>>>>>>>>> context, there can only be one
>>>>>>>>>>> parameter "mainDecoratorLocation" for both webapps.
>>>>>>>>>>>
>>>>>>>>>>> BJ's method is the only quick fix there is. Decouple
>>>>>>>>>>> "mainDecoratorLocation" from the global servlet context, and
>>>>>>>>>>> encapsulate that attribute together with the
>>>>>>>>>>> widgets that require that particular attribute with a particular
>>>>>>>>>>> value.
>>>>>>>>>>>
>>>>>>>>>>> That means changing all widgets to point to say
>>>>>>>>>>> "<webapp-name>:mainDecoratorLocation". Another solution could be
>>>>>>>>>>> to add a new attribute to <decorator-screen>, like
>>>>>>>>>>> "param-location" which automatically hunts for a parameter named
>>>>>>>>>>> "<webapp-name>:mainDecoratorLocation". So a value of
>>>>>>>>>>> "myDecoratorLocation" might prompt the widget engine to look for
>>> a
>>>>>>>>>>> parameter named "<webapp-name>:myDecoratorLocation".
>>>>>>>>>>>
>>>>>>>>>>> That is a simple fix.
>>>>>>>>>>>
>>>>>>>>>>> For a better fix, we need to truly decouple
>>> "mainDecoratorLocation"
>>>>>>>>>>> from the global servlet context (web.xml), and put it into the
>>>>>>>>>>> controller.xml. The widget
>>>>>>>>>>> engine could look in the controller.xml for a variable
>>>>>>>>>>> "mainDecoratorLocation" every time it
>>>>>>>>>>> processes a screen widget. That would ensure perfect
>>> re-usability
>>>>>>>>>>> of any included widgets
>>>>>>>>>>> (included with a controller <include>), without the need to
>>> meddle
>>>>>>>>>>> with passing in the expected
>>>>>>>>>>> "mainDecoratorLocation" for those included widgets.
>>>>>>>>>>>
>>>>>>>>>>> Some changes to ConfigXMLReader, RequestManager and
>>> ControlServlet
>>>>>>>>>> may
>>>>>>>>>>> be required.
>>>>>>>>>>>
>>>>>>>>>>> Hope that makes sense.
>>>>>>>>>>>
>>>>>>>>>>> I love how OFBiz already has many powerful "clean extension"
>>>>>>>>>>> mechanisms, much like object-oriented programming and
>>>>>>>>>>> sub-classing. This "mainDecoratorLocation" thing may
>>>>>>>>>> be
>>>>>>>>>>> a good area to work on.
>>>>>>>>>>>
>>>>>>>>>>> Jonathon
>>>>>>>>>>>
>>>>>>>>>>> BJ Freeman wrote:
>>>>>>>>>>>> so far you and I are on the same page.
>>>>>>>>>>>> I thinks the confusion is, I am not defining a
>>>>>>>>> mainDecoratorLocation
>>>>>>>>>>>> for my application. So this is not about how to use
>>>>>>>>>>> ainDecoratorLocation
>>>>>>>>>>>> in my web.xml for my widgets.
>>>>>>>>>>>> the web.xml has been used to provide context for widget's
>>>>>>>>>>>> mainDecoratorLocation, which as you point out is a component.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> here are the steps:
>>>>>>>>>>>> include another controller in your apps controller.
>>>>>>>>>>>> Now the mainDecoratorLocation is defined in the web.xml of the
>>>>>>>>>>> included
>>>>>>>>>>>> controller, but not mine.
>>>>>>>>>>>> so if I don't delcare a mainDecoratorLocation in my web.xml I
>>> get
>>>>>>>>> an
>>>>>>>>>>>> error, about the mainDecoratorLocation not being found, when I
>>>>>>>>>> access
>>>>>>>>>>>> the included controls widget.
>>>>>>>>>>>> If I define a mainDecoratorLocation in my web.xml that has the
>>>>> path
>>>>>>>>>>> for
>>>>>>>>>>>> one of the application that is included in my controller, it
>>> works
>>>>>>>>>>> fine.
>>>>>>>>>>>> But just for that application.
>>>>>>>>>>>> This lets me only define one mainDecoratorLocation for all
>>>>> included
>>>>>>>>>>>> controllers.
>>>>>>>>>>>> so I can not define a mainDecoratorLocation in my web.xml for
>>> each
>>>>>>>>>>>> application with the path defined in the application web.xml.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Chris Howe sent the following on 11/21/2007 6:39 PM:
>>>>>>>>>>>>> No, the feature of mainDecoratorLocation is the webapp being
>>>>>>>>> called
>>>>>>>>>>> defines the default value of mainDecoratorLocation. You should
>>> be
>>>>>>>>>> able
>>>>>>>>>>> to run a pre-processor to override the value that is found in
>>> the
>>>>>>>>>>> called webapp's web.xml file.
>>>>>>>>>>>>> It may help to identify here the difference in terminology that
>>>>> is
>>>>>>>>>>> used. There's a component and a web application. The web
>>>>>>>>>> application
>>>>>>>>>>> is what is generally under the webapp folder and does not
>>> include
>>>>>>>>>> the
>>>>>>>>>>> widgets. The widgets (form, screen, tree, menu) belong to the
>>>>>>>>>> component,
>>>>>>>>>>> not the webapp.
>>>>>>>>>>>>> The controller controls the web application along with the
>>>>> context
>>>>>>>>>>> provided by the web.xml definitions. So, if I have webapp:
>>> myApp,
>>>>>>>>>> the
>>>>>>>>>>> context should be provided by the web.xml file in the web
>>>>>>>>>> application
>>>>>>>>>>> myApp, at least by default. Simply because you are including
>>>>>>>>>> elements
>>>>>>>>>>> from another document does not mean you should change what
>>>>> provides
>>>>>>>>>> the
>>>>>>>>>>> default context.
>>>>>>>>>>>>> webapp/myApp
>>>>>>>>>>>>> /WEB-INF
>>>>>>>>>>>>> /controller.xml
>>> <--Controls
>>>>>>>>>>> web application myApp
>>>>>>>>>>>>> /web.xml
>>>>>>>>> <--provides
>>>>>>>>>>> context for web application myApp
>>>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>> Sent: Wednesday, November 21, 2007 7:59:52 PM
>>>>>>>>>>>>> Subject: Re: mainDecoratorLocation change to
>>>>>>>>>>> [applicationname]mainDecoratorLocation
>>>>>>>>>>>>> If i understand you correctly the path to mainDecoratorLocation
>>>>>>>>>>> should
>>>>>>>>>>>>> be the same for all apps.
>>>>>>>>>>>>> however if the path is in the application should it not be
>>>>>>>>>>> distinguish
>>>>>>>>>>>>> for that application?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris Howe sent the following on 11/21/2007 5:50 PM:
>>>>>>>>>>>>>> The "problem" that you're having is the exact feature that is
>>>>>>>>>>> created
>>>>>>>>>>>>> by mainDecoratorLocation. Appending [applicationname] breaks
>>>>>>>>> that
>>>>>>>>>>>>> feature. Are you unable to override
>>>>>>>>>>> parameters.mainDecoratorLocation
>>>>>>>>>>>>> through a preprocessor or by another means?
>>>>>>>>>>>>>> ----- Original Message ----
>>>>>>>>>>>>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>>> Sent: Wednesday, November 21, 2007 7:02:18 PM
>>>>>>>>>>>>>> Subject: mainDecoratorLocation change to
>>>>>>>>>>>>> [applicationname]mainDecoratorLocation
>>>>>>>>>>>>>> when including other controllers, the context for
>>>>>>>>>>>>> mainDecoratorLocation
>>>>>>>>>>>>>> has to be defined in the web.xml of the home controller
>>>>> location.
>>>>>>>>>>>>>> this causes a problem when all the application use
>>>>>>>>>>>>>> mainDecoratorLocation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> so would like to propose that the mainDecoratorLocation is
>>> used
>>>>>>>>>> for
>>>>>>>>>>>>> the
>>>>>>>>>>>>>> framework/common/webapp/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and preappend the application name to mainDecoratorLocation
>>>>>>>>>>>>>> ([applicationname]mainDecoratorLocation) in the applications
>>>>>>>>>>>>> web.xml.
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG Free Edition.
>>>> Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date:
>>> 11/22/2007 6:55 PM
>>>
>>>
>
>
>
