Hi Scott, 2010/5/3 Scott Gray <[email protected]>
> 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. > OK, I see what you mean. > - 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. > What I think we should try to do is to have a standard menu definition in a menus file and have a the injection tag to specify where to inject the menu. This would keep the menu definition exactly the same as it is now. A menu could be used alone as we use it right now and be injected somewhere at the same time. -Bruno > > 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 > >>> > >> > >> > >
