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
> >
>
>
