Controller Injection
Locked
12
12
Controller Injection
 
|
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. Thoughts? Thanks Scott HotWax Media http://www.hotwaxmedia.com |
smime.p7s (3K)
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Re: Controller Injection
|
|
In reply to this post by Bob Morley
On 30/04/2010, at 4: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] > </ ... Not 100% sure what you mean there. > 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). Not entirely sure I follow you there, the existing model whereby you replace the legacy webapp with a new one from hot-deploy does what you describe above i.e. it only contains your modifications to the original because you use include-controller and then only override what you need to. > 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 ... I wasn't aware of services having that capability, I'll have to look into it sometime as it sounds interesting. But back to the point, I'm not entirely sure I understand what a global definition would mean from controller entries? > PS. You can see I used "override" instead of "extend" because it seem more > clear to me what it was doing. To me override means to "replace" whereas extend means "inherit and alter", the latter feels clearer to me since it is much more analogous to extending a class then it is to overriding a method. Regards Scott |
Re: Controller Injection
|
|
In reply to this post by David E. Jones-2
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. > 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 |
Re: Controller Injection
|
|
In reply to this post by Scott Gray-2
On 30/04/2010, at 1:49 PM, Scott Gray wrote:
> What about adding something like the following to ofbiz-component.xml schema > <extend-web-app name="order" > include-controller="path/to/controller.xml" > /> Finding the webapp to extend doesn't look so easy, it looks like it would need to be something like: <extend-webapp server-name="default-server" mount-point="/ordermgr"> That would be the only way to be sure that you're extending the correct webapp. The name attribute is really only informational and does nothing, I could for example name every webapp in OFBiz "order" and it would have no effect whatsoever. Regards Scott |
Re: Controller Injection
|
|
Re: Controller Injection
|
|
On 1/05/2010, at 3:56 AM, Adam Heath wrote:
> Scott Gray wrote: >> On 30/04/2010, at 1:49 PM, Scott Gray wrote: >> >>> What about adding something like the following to ofbiz-component.xml schema >>> <extend-web-app name="order" >>> include-controller="path/to/controller.xml" >>> /> >> >> Finding the webapp to extend doesn't look so easy, it looks like it would need to be something like: >> <extend-webapp server-name="default-server" mount-point="/ordermgr"> >> That would be the only way to be sure that you're extending the correct webapp. The name attribute is really only informational and does nothing, I could for example name every webapp in OFBiz "order" and it would have no effect whatsoever. > > <webapp> should be defined separately from the mount point it is > attached too. Not all in one as it is now. > > Then, we could extend the webapp, or add more mappings on other servers. <webapp location="../../applications/order/webapp/ordermgr" ... Regards Scott |
Re: Controller Injection
|
|
In reply to this post by Scott Gray-2
On 1/05/2010, at 12:35 AM, Scott Gray wrote:
> On 30/04/2010, at 1:49 PM, Scott Gray wrote: > >> What about adding something like the following to ofbiz-component.xml schema >> <extend-web-app name="order" >> include-controller="path/to/controller.xml" >> /> > > Finding the webapp to extend doesn't look so easy, it looks like it would need to be something like: > <extend-webapp server-name="default-server" mount-point="/ordermgr"> > That would be the only way to be sure that you're extending the correct webapp. The name attribute is really only informational and does nothing, I could for example name every webapp in OFBiz "order" and it would have no effect whatsoever. <!-- extends the catalog webapp with the ordermgr's controller from a hot-deploy component --> <extend-webapp server="default-server" mount-point="/catalog"> <controller-extension location="../../applications/order/webapp/ordermgr/WEB-INF/controller.xml"/> </extend-webapp> and: <!-- extends the catalog's controller with the ordermgr's controller from a hot-deploy component --> <extend-controller base-location="component://product/webapp/catalog/WEB-INF/controller.xml" extend-location="component:///order/webapp/ordermgr/WEB-INF/controller.xml"/> And I prefer the latter for a number of reasons: - The former requires that you supply a ServletContext (or server name and mount point) when retrieving a ControllerConfig and a number of calling methods do not have that information available - The latter doesn't depend on the mount point or server name meaning that you can change them at will without breaking the extensions - The latter allows you to extend controllers that don't have a webapp, for example you can extend common-controller.xml and then your extensions will be available to everything that includes it. - The implementation on the latter feels a lot cleaner Any thoughts? Both work and I really like this feature, having the ability to plug additional functionality into the base apps so easily seems pretty cool. It's a pity I didn't decide to work on this earlier for 10.04. I think the next step would be to add a similar type of feature for extending the menu widget so that you don't have to override view-maps/screens to add access to extensions. Regards Scott |
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Re: Controller Injection
|
|
In reply to this post by Bruno Busco
To me extend seems clear but I agree it does conflict with the way that term is used elsewhere in the framework. I don't really like merge though, it doesn't feel like an accurate description of what is happening. Any other ideas anyone?
Either way, I'd document the xsd so no one will be confused for very long. For menus, I think it would need to be similar to this controller approach, the framework will need to know about the extensions beforehand. I haven't really thought much about extending menus at this stage, I'll give it some thought and send any ideas here when they come to me. Regards Scott On 2/05/2010, at 6:04 PM, Bruno Busco wrote: > Thank you Scott for working on this feature. > "plug-in" type extensions will help a lot. > > I agree with you, I prefer the latter solution also. > It simply overrides the entries in a single file with the ones contentained > in a new one. Crystal clear. > > Wouldn't it be better to use the "merge" term instead of the "extend" to > differentiate from the "extension" mechanism that is already in place? > > About the menu widget, I remember we talk about some time ago. > At that time I proposed something like a "merge" feature more than an > extension. > This was because base menu items should be added/modified/deleted in the > plugin file. > There should be also some way to specify in which place the new menu entries > are shown in the existent menu. > > Thank you, > Bruno > > 2010/5/2 Scott Gray <[hidden email]> > >> On 1/05/2010, at 12:35 AM, Scott Gray wrote: >> >>> On 30/04/2010, at 1:49 PM, Scott Gray wrote: >>> >>>> What about adding something like the following to ofbiz-component.xml >> schema >>>> <extend-web-app name="order" >>>> include-controller="path/to/controller.xml" >>>> /> >>> >>> Finding the webapp to extend doesn't look so easy, it looks like it would >> need to be something like: >>> <extend-webapp server-name="default-server" mount-point="/ordermgr"> >>> That would be the only way to be sure that you're extending the correct >> webapp. The name attribute is really only informational and does nothing, I >> could for example name every webapp in OFBiz "order" and it would have no >> effect whatsoever. >> >> So I ended up doing two implementations: >> <!-- extends the catalog webapp with the ordermgr's controller from a >> hot-deploy component --> >> >> <extend-webapp server="default-server" mount-point="/catalog"> >> <controller-extension >> location="../../applications/order/webapp/ordermgr/WEB-INF/controller.xml"/> >> </extend-webapp> >> >> and: >> <!-- extends the catalog's controller with the ordermgr's controller >> from a hot-deploy component --> >> >> <extend-controller >> base-location="component://product/webapp/catalog/WEB-INF/controller.xml" >> >> extend-location="component:///order/webapp/ordermgr/WEB-INF/controller.xml"/> >> >> And I prefer the latter for a number of reasons: >> - The former requires that you supply a ServletContext (or server name and >> mount point) when retrieving a ControllerConfig and a number of calling >> methods do not have that information available >> - The latter doesn't depend on the mount point or server name meaning that >> you can change them at will without breaking the extensions >> - The latter allows you to extend controllers that don't have a webapp, for >> example you can extend common-controller.xml and then your extensions will >> be available to everything that includes it. >> - The implementation on the latter feels a lot cleaner >> >> Any thoughts? >> >> Both work and I really like this feature, having the ability to plug >> additional functionality into the base apps so easily seems pretty cool. >> It's a pity I didn't decide to work on this earlier for 10.04. >> >> I think the next step would be to add a similar type of feature for >> extending the menu widget so that you don't have to override >> view-maps/screens to add access to extensions. >> >> Regards >> Scott |
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Re: Controller Injection
|
|
On 3/05/2010, at 11:41 AM, Bob Morley wrote:
> Bruno Busco wrote: >> >> 2010/5/2 Scott Gray <[hidden email]> >> >>> To me extend seems clear but I agree it does conflict with the way that >>> term is used elsewhere in the framework. I don't really like merge >>> though, >>> it doesn't feel like an accurate description of what is happening. Any >>> other ideas anyone? >>> >> >> What about "overrides" ? >> > > When i first read of the feature I felt "override" was appropriate because > the original use case was defined in terms of overriding a view-map entry. > But (without looking at the implementation) I think you could use this as an > extension as well ... for example, you could likely provide a new > view-handler (extension) to go along with an override view-map, and that > newly rendered form could postback to a new request-map (extension). So I > understand why Scott felt "extend" was the right term ... > I wonder if this is really just external modification to a controller. That's exactly what it is. > Terms that felt kinda close were stuff like application, > external-definition, enhance ... perhaps something in that ballpark could be > used to define exactly what is happening here ? To be honest extend still feels like the best fit to me but what about the term I used in the subject line: inject? Regards Scott |
Re: Controller Injection
|
|
In reply to this post by Scott Gray-2
Okay for the naming, how about we add a wrapping element that would contain all of our "plug-in" information:
(we could replace inject with plug-ins or something) <inject> <controller base-location="component://path/to/base/controller.xml" include-location="component://path/to/additional/controller.xml"/> <menu-widget location="component://path/to/additional/PlugInMenus.xml"/> <!-- screen-widget? (add/replace sections, extend or override actions)--> <!-- forms-widget? (add/replace fields, extend/override actions) --> <!-- uiLabels? (in services and maybe elsewhere I don't think you can replace some labels unless you edit or completely replace a UiLabel file --> </inject> That would nicely group all plug-in information in one spot. Another option for the *-widget and uiLabels would be to use existing *-resource element pattern because they are only pointing to individual locations/files, but it wouldn't work for the controller because it needs two location attributes. And then for menus we have something like this: (menu-plugins?) <menu-injections> <menu-injection location="component://accounting/widget/AccountingMenus.xml" name="AccountingAppBar"> <actions type="override | extend"><!-- Either replace existing actions or execute these after them --></actions> <add type="before" name="invoices"> <menu-item name="reconciliations" title="Reconciliations"><link target="reconciliations"/></menu-item> </add> <add type="after" name="invoices"> <menu-item name="somethingelse" title="Something Else!"><link target="somethingelse"/></menu-item> </add> <!-- maybe this replace tag isn't necessary and we can just replace existing menu items when there is a name match or otherwise add to the end --> <replace> <menu-item name="invoices" title="Super Invoices!"><link target="superInvoices"/></menu-item> </replace> </menu-injection> </menu-injections> Thoughts? Thanks Scott HotWax Media http://www.hotwaxmedia.com On 2/05/2010, at 11:53 PM, Scott Gray wrote: > To me extend seems clear but I agree it does conflict with the way that term is used elsewhere in the framework. I don't really like merge though, it doesn't feel like an accurate description of what is happening. Any other ideas anyone? > > Either way, I'd document the xsd so no one will be confused for very long. > > For menus, I think it would need to be similar to this controller approach, the framework will need to know about the extensions beforehand. I haven't really thought much about extending menus at this stage, I'll give it some thought and send any ideas here when they come to me. > > Regards > Scott > > On 2/05/2010, at 6:04 PM, Bruno Busco wrote: > >> Thank you Scott for working on this feature. >> "plug-in" type extensions will help a lot. >> >> I agree with you, I prefer the latter solution also. >> It simply overrides the entries in a single file with the ones contentained >> in a new one. Crystal clear. >> >> Wouldn't it be better to use the "merge" term instead of the "extend" to >> differentiate from the "extension" mechanism that is already in place? >> >> About the menu widget, I remember we talk about some time ago. >> At that time I proposed something like a "merge" feature more than an >> extension. >> This was because base menu items should be added/modified/deleted in the >> plugin file. >> There should be also some way to specify in which place the new menu entries >> are shown in the existent menu. >> >> Thank you, >> Bruno >> >> 2010/5/2 Scott Gray <[hidden email]> >> >>> On 1/05/2010, at 12:35 AM, Scott Gray wrote: >>> >>>> On 30/04/2010, at 1:49 PM, Scott Gray wrote: >>>> >>>>> What about adding something like the following to ofbiz-component.xml >>> schema >>>>> <extend-web-app name="order" >>>>> include-controller="path/to/controller.xml" >>>>> /> >>>> >>>> Finding the webapp to extend doesn't look so easy, it looks like it would >>> need to be something like: >>>> <extend-webapp server-name="default-server" mount-point="/ordermgr"> >>>> That would be the only way to be sure that you're extending the correct >>> webapp. The name attribute is really only informational and does nothing, I >>> could for example name every webapp in OFBiz "order" and it would have no >>> effect whatsoever. >>> >>> So I ended up doing two implementations: >>> <!-- extends the catalog webapp with the ordermgr's controller from a >>> hot-deploy component --> >>> >>> <extend-webapp server="default-server" mount-point="/catalog"> >>> <controller-extension >>> location="../../applications/order/webapp/ordermgr/WEB-INF/controller.xml"/> >>> </extend-webapp> >>> >>> and: >>> <!-- extends the catalog's controller with the ordermgr's controller >>> from a hot-deploy component --> >>> >>> <extend-controller >>> base-location="component://product/webapp/catalog/WEB-INF/controller.xml" >>> >>> extend-location="component:///order/webapp/ordermgr/WEB-INF/controller.xml"/> >>> >>> And I prefer the latter for a number of reasons: >>> - The former requires that you supply a ServletContext (or server name and >>> mount point) when retrieving a ControllerConfig and a number of calling >>> methods do not have that information available >>> - The latter doesn't depend on the mount point or server name meaning that >>> you can change them at will without breaking the extensions >>> - The latter allows you to extend controllers that don't have a webapp, for >>> example you can extend common-controller.xml and then your extensions will >>> be available to everything that includes it. >>> - The implementation on the latter feels a lot cleaner >>> >>> Any thoughts? >>> >>> Both work and I really like this feature, having the ability to plug >>> additional functionality into the base apps so easily seems pretty cool. >>> It's a pity I didn't decide to work on this earlier for 10.04. >>> >>> I think the next step would be to add a similar type of feature for >>> extending the menu widget so that you don't have to override >>> view-maps/screens to add access to extensions. >>> >>> Regards >>> Scott > |
Re: Controller Injection
|
|
Re: Controller Injection
|
|
Hi Bruno,
Thanks for taking a look, here's a couple of points about your suggestions: - You can't mix and match attributes like that on a single element, you'd need to have a separate element for each attribute set. - I really wanted to avoid putting too much definition in the component file itself, I'd rather it simply declared them rather than try to define them. If you have a lot of extensions it would be much easier to break the definitions up into separate files. Thanks Scott On 3/05/2010, at 11:41 PM, Bruno Busco wrote: > Hi Scott, > > could we consider to use the ofbiz-component.xml file to contain all the > injections like follows? > > <ofbiz-component name="ExtendingAccounting" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:noNamespaceSchemaLocation=" > http://ofbiz.apache.org/dtds/ofbiz-component.xsd"> > > <extension-resource type="controller" base-location="component:// > path/to/base/controller.xml" > location="component://path/to/additional/controller.xml"/> > > <extension-resource type="menu" base-menu="AccountingAppBar" > base-menu-location="component://accounting/widget/AccountingMenus.xml" > base-menu-before-item="invoices" menu="NewMenuBefore" > location="component://accounting/widget/NewMenus.xml"/> > > <extension-resource type="menu" base-menu="AccountingAppBar" > base-menu-location="component://accounting/widget/AccountingMenus.xml" > base-menu-after-item="invoices" menu="NewMenuAfter" > location="component://accounting/widget/NewMenus.xml"/> > </ofbiz-component> > > We would need only one new tag <extension-resource> with type=(controller, > menu, etc.) > For menu injections the NewMenus.xml would be a standard nemus file. > All items in NewMenuBefore menu will be added before the "invoice" items. > All items in NewMenuAfter menu will be added after the "invoice" items. > > My 2 cents, > Bruno > > 2010/5/3 Scott Gray <[hidden email]> > >> Okay for the naming, how about we add a wrapping element that would contain >> all of our "plug-in" information: >> (we could replace inject with plug-ins or something) >> <inject> >> <controller base-location="component://path/to/base/controller.xml" >> include-location="component://path/to/additional/controller.xml"/> >> <menu-widget location="component://path/to/additional/PlugInMenus.xml"/> >> <!-- screen-widget? (add/replace sections, extend or override >> actions)--> >> <!-- forms-widget? (add/replace fields, extend/override actions) --> >> <!-- uiLabels? (in services and maybe elsewhere I don't think you can >> replace some labels unless you edit or completely replace a UiLabel file --> >> </inject> >> >> That would nicely group all plug-in information in one spot. Another >> option for the *-widget and uiLabels would be to use existing *-resource >> element pattern because they are only pointing to individual >> locations/files, but it wouldn't work for the controller because it needs >> two location attributes. >> >> And then for menus we have something like this: >> (menu-plugins?) >> <menu-injections> >> <menu-injection >> location="component://accounting/widget/AccountingMenus.xml" >> name="AccountingAppBar"> >> <actions type="override | extend"><!-- Either replace existing >> actions or execute these after them --></actions> >> >> <add type="before" name="invoices"> >> <menu-item name="reconciliations" title="Reconciliations"><link >> target="reconciliations"/></menu-item> >> </add> >> <add type="after" name="invoices"> >> <menu-item name="somethingelse" title="Something Else!"><link >> target="somethingelse"/></menu-item> >> </add> >> >> <!-- maybe this replace tag isn't necessary and we can just replace >> existing menu items when there is a name match or otherwise add to the end >> --> >> <replace> >> <menu-item name="invoices" title="Super Invoices!"><link >> target="superInvoices"/></menu-item> >> </replace> >> </menu-injection> >> </menu-injections> >> >> Thoughts? >> >> Thanks >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 2/05/2010, at 11:53 PM, Scott Gray wrote: >> >>> To me extend seems clear but I agree it does conflict with the way that >> term is used elsewhere in the framework. I don't really like merge though, >> it doesn't feel like an accurate description of what is happening. Any >> other ideas anyone? >>> >>> Either way, I'd document the xsd so no one will be confused for very >> long. >>> >>> For menus, I think it would need to be similar to this controller >> approach, the framework will need to know about the extensions beforehand. >> I haven't really thought much about extending menus at this stage, I'll >> give it some thought and send any ideas here when they come to me. >>> >>> Regards >>> Scott >>> >>> On 2/05/2010, at 6:04 PM, Bruno Busco wrote: >>> >>>> Thank you Scott for working on this feature. >>>> "plug-in" type extensions will help a lot. >>>> >>>> I agree with you, I prefer the latter solution also. >>>> It simply overrides the entries in a single file with the ones >> contentained >>>> in a new one. Crystal clear. >>>> >>>> Wouldn't it be better to use the "merge" term instead of the "extend" to >>>> differentiate from the "extension" mechanism that is already in place? >>>> >>>> About the menu widget, I remember we talk about some time ago. >>>> At that time I proposed something like a "merge" feature more than an >>>> extension. >>>> This was because base menu items should be added/modified/deleted in the >>>> plugin file. >>>> There should be also some way to specify in which place the new menu >> entries >>>> are shown in the existent menu. >>>> >>>> Thank you, >>>> Bruno >>>> >>>> 2010/5/2 Scott Gray <[hidden email]> >>>> >>>>> On 1/05/2010, at 12:35 AM, Scott Gray wrote: >>>>> >>>>>> On 30/04/2010, at 1:49 PM, Scott Gray wrote: >>>>>> >>>>>>> What about adding something like the following to ofbiz-component.xml >>>>> schema >>>>>>> <extend-web-app name="order" >>>>>>> include-controller="path/to/controller.xml" >>>>>>> /> >>>>>> >>>>>> Finding the webapp to extend doesn't look so easy, it looks like it >> would >>>>> need to be something like: >>>>>> <extend-webapp server-name="default-server" mount-point="/ordermgr"> >>>>>> That would be the only way to be sure that you're extending the >> correct >>>>> webapp. The name attribute is really only informational and does >> nothing, I >>>>> could for example name every webapp in OFBiz "order" and it would have >> no >>>>> effect whatsoever. >>>>> >>>>> So I ended up doing two implementations: >>>>> <!-- extends the catalog webapp with the ordermgr's controller from a >>>>> hot-deploy component --> >>>>> >>>>> <extend-webapp server="default-server" mount-point="/catalog"> >>>>> <controller-extension >>>>> >> location="../../applications/order/webapp/ordermgr/WEB-INF/controller.xml"/> >>>>> </extend-webapp> >>>>> >>>>> and: >>>>> <!-- extends the catalog's controller with the ordermgr's controller >>>>> from a hot-deploy component --> >>>>> >>>>> <extend-controller >>>>> >> base-location="component://product/webapp/catalog/WEB-INF/controller.xml" >>>>> >>>>> >> extend-location="component:///order/webapp/ordermgr/WEB-INF/controller.xml"/> >>>>> >>>>> And I prefer the latter for a number of reasons: >>>>> - The former requires that you supply a ServletContext (or server name >> and >>>>> mount point) when retrieving a ControllerConfig and a number of calling >>>>> methods do not have that information available >>>>> - The latter doesn't depend on the mount point or server name meaning >> that >>>>> you can change them at will without breaking the extensions >>>>> - The latter allows you to extend controllers that don't have a webapp, >> for >>>>> example you can extend common-controller.xml and then your extensions >> will >>>>> be available to everything that includes it. >>>>> - The implementation on the latter feels a lot cleaner >>>>> >>>>> Any thoughts? >>>>> >>>>> Both work and I really like this feature, having the ability to plug >>>>> additional functionality into the base apps so easily seems pretty >> cool. >>>>> It's a pity I didn't decide to work on this earlier for 10.04. >>>>> >>>>> I think the next step would be to add a similar type of feature for >>>>> extending the menu widget so that you don't have to override >>>>> view-maps/screens to add access to extensions. >>>>> >>>>> Regards >>>>> Scott >>> >> >> |
| Free forum by Nabble | Edit this page |