On 30/04/2010, at 5:07 PM, David E Jones wrote: > 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.
I've been having a lot of similar thoughts lately about increasingly the runtime flexibility of the view layer and this sounds like interesting stuff, I'll definitely have to have a look and see what ideas can be stolen :-) > 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. Maybe I'm naive but I really don't think there is any move that is too bold to make if it is going to deliver significant improvements. I really couldn't care less about backwards compatibility if it starts to significantly hinder our ability to move forward. Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
