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 <scott.g...@hotwaxmedia.com>
>>
>>> 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
