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 <[email protected]> > >> 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 <[email protected]> >>>> >>>>> 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 >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
