Controller Injection

[Bruno Busco]

Hi Scott,

2010/5/3 Scott Gray <[hidden email]>

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

[Scott Gray-2]

On 4/05/2010, at 8:02 AM, Bruno Busco wrote:

> Hi Scott,
>
> 2010/5/3 Scott Gray <[hidden email]>
>
>> 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.

I thought about this but there were a couple of things I didn't like:
- I don't think you should be able to alter the menu element, if multiple extensions tried to do that then it would just up end being a big mess (although I could be wrong about this and developers would just need to be careful)
- Separating the two means more work when you want to extend a menu, you'd have to define a menu in one file and then also define how it should be merged with the base menu

Although it should be possible to support both approaches, where you can either define new menu items inline or just point to a separate menu definition and then describe the merge.  I'll have a think on what the schema might look like.

Thanks
Scott