I am willing to put the mainDecorationLocation somewhere besides the web.xml is it is a component item. So where should it be put so it is reference as a component. maybe put it in the controller like the view screens of components? that way it is alway specific to that component.
I don't see how a preprocessor in my controller would work. it if does not know where the mainDecorationLocation is associated with. Chris Howe sent the following on 11/21/2007 9:28 PM: > 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. >>>> >>>> >>>> >>> >>> >>> >>> >> > > > > > > >
