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