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