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