Ok so the include for controller was only meant for the local app.
that said.
I will implement the easiest way for me, which is to modify each app so
I can define appname-main-decorator in my web.xml, as I originally
proposed.
however I will not burden the trunk with this concept.
save the heavy stuff for when I have more time.
Got a lot on my plate now.
Jonathon -- Improov sent the following on 11/23/2007 4:28 AM:
> BJ,
>
> I think many things in life are "work-in-progress", even released
> versions of software. (Yeah, I know, I'll be fired if I'm in product
> marketing.)
>
> That said, I humbly and apologetically put to you (and to myself) that
> the <include> directive in controller.xml is not designed for blindly
> including another webapp's request/view dictionary (controller.xml) and
> have it all work like Object-oriented Java programming. See my analogy
> with ordering a hamburger from a different POS machine in the same
> restaurant. No, the <include> directive can't fix that.
>
> So what is the <include> directive for? What can it do now?
>
> To organize a large controller.xml into smaller ones. We could have a
> main controller.xml that includes requests.xml and views.xml, and maybe
> even handlers.xml . (Can this be done? Verify?) Or organize by function,
> rather than by directives (ie, not by <request-map>, <view-map>, etc).
>
> To clone an original webapp, and to call on its requests and views with
> a mainDecoratorLocation that works with its screen widgets. The
> mainDecoratorLocation can point to a decorator that is either original
> or modified-but-compatible.
>
> To extend that original webapp with more requests, or with more views
> and screen widgets that can also use the same decorator mentioned above.
>
> What is it not used for?
>
> Combining multiple webapps that may need different mainDecoratorLocation
> values.
>
> In short, I'm sorry to say that the <include> directive is not an
> "object-oriented" mechanism used to call on an entire webapp
> encapsulated in a clean abstraction (using its own mainDecoratorLocation
> without us having to know what that is).
>
> But I fully support your ambition to expand the <include> directive's
> capabilities, as I had amply indicated in this thread. I had even
> highlighted the areas that need work to fulfill your ambition. I do hope
> you will continue your exploration. I await your findings eagerly, and
> may even jump in at points where I feel I can help out. :)
>
> Jonathon
>
> BJ Freeman wrote:
>> let me refocus this conversation.
>> this is about using the include in the controller to access other
>> controllers.
>> This is a feature of ofbiz is it not?
>> In using this feature there is a problem when the included controller
>> accesses a widget in its application.
>>
>> So either remove the feature or make it work correctly.
>>
>>
>> Scott Gray sent the following on 11/22/2007 9:48 PM:
>>> 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.xml for
>>>>>>>> <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.
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>
>>
>
>
>
>
