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