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