On Apr 29, 2010, at 10:12 PM, Bob Morley wrote: > > > Scott Gray-2 wrote: >> >> What about adding something like the following to ofbiz-component.xml >> schema >> <extend-web-app name="order" >> include-controller="path/to/controller.xml" >> /> >> >> This would basically be similar to the "include" element available in the >> controller schema except that it would override any elements in the >> web-app's normal controller. >> >> Doing this would allow us to externally override any requests and views in >> a base application's controller without needing to completely replace the >> existing webapp and could be a good starting point for building "plug-in" >> support. >> >> Say for example you simply want to make a few changes to the EditProduct >> screen, you could just override the view-mapping to point to a screen in >> your custom component and boom, you're done. >> > > I really like the concept. Building on this, two variances for your > consideration came to mind ... > > <request-map webapp-name="partymgr" uri="EditParty"> ... > <view-map webapp-name="partymgr" name="EditParty" type="view" ... > > OR a new element ... > > <controller-override webapp="partymgr"> > [standard request & view maps elements] > </ ... > > This came from a perceived desire to be more granular in what I override in > another application. The other is to be able to separate out my "overrides" > from my standard controller. ie. I could see having a controller.xml and a > controller-override.xml (where controller.xml includes override). > > The other thought is maybe consider a "global" definition -- I believe > services does there service definitions are in general global, but the > infrastructure is in place to have a local set of services (I think it keeps > two maps and looks in "local" for your dispatcher first). If memory > services, there are not examples of this usage in OOB Ofbiz mind you. > Naturally name collisions become a real consideration with this type of > thing ... > > PS. You can see I used "override" instead of "extend" because it seem more > clear to me what it was doing.
The nice thing about Scott's suggestion is you have to do less file scanning and loading to find out that there are extensions/overrides. One thing I've thought for a long time is that it would be nice to not have to load so much just to get things running, ie do more lazy loading in the framework. Right now widgets are lazy-loaded, but that's it (entities, services, controllers, etc are all loaded on startup for every component and webapp). In Moqui this is a little easier as there is no controller.xml and instead request mapping and transitions out of screens are part of the screen definitions. To help avoid having to preload everything on startup (and enable more lazy loading) I put external subscreen (menu items, requests, etc rolled into one) extensions and overrides in the database. That may seem crazy, but in Moqui it is more of a general trend with configurable screens and forms where you still define them in XML, but there are certain changes users can do on the fly through the database, changes that are targeted at a less technical audience but still providing some flexibility. In OFBiz some of these concepts may be useful. There are already some database driven things in the framework, and it might work for this too. I don't know if it's really possible at this point with OFBiz, but I'd rather move toward more lazy-load-ability rather than away from it. -David
