You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Scott Gray <sc...@hotwaxmedia.com> on 2010/04/30 03:49:21 UTC
Controller Injection
What about adding something like the following to ofbiz-component.xml schema
<extend-web-app name="order"
include-controller="path/to/controller.xml"
/>
This would basically be similar to the "include" element available in the controller schema except that it would override any elements in the web-app's normal controller.
Doing this would allow us to externally override any requests and views in a base application's controller without needing to completely replace the existing webapp and could be a good starting point for building "plug-in" support.
Say for example you simply want to make a few changes to the EditProduct screen, you could just override the view-mapping to point to a screen in your custom component and boom, you're done.
Thoughts?
Thanks
Scott
HotWax Media
http://www.hotwaxmedia.com
Re: Controller Injection
Posted by David E Jones <de...@me.com>.
This would allow you to add controller entries to existing apps, but how would you handle other parts that need UI extensions, like menu items and such?
-David
On May 1, 2010, at 8:03 PM, Scott Gray wrote:
> 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
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 3/05/2010, at 11:41 AM, Bob Morley wrote:
> Bruno Busco wrote:
>>
>> 2010/5/2 Scott Gray <sc...@hotwaxmedia.com>
>>
>>> 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?
>>>
>>
>> What about "overrides" ?
>>
>
> When i first read of the feature I felt "override" was appropriate because
> the original use case was defined in terms of overriding a view-map entry.
> But (without looking at the implementation) I think you could use this as an
> extension as well ... for example, you could likely provide a new
> view-handler (extension) to go along with an override view-map, and that
> newly rendered form could postback to a new request-map (extension). So I
> understand why Scott felt "extend" was the right term ...
Yeah, it's very similar how a controller uses the "include" tag and then either overrides included entries (handlers, requests, views) or adds new ones.
> I wonder if this is really just external modification to a controller.
That's exactly what it is.
> Terms that felt kinda close were stuff like application,
> external-definition, enhance ... perhaps something in that ballpark could be
> used to define exactly what is happening here ?
To be honest extend still feels like the best fit to me but what about the term I used in the subject line: inject?
Regards
Scott
Re: Controller Injection
Posted by Bob Morley <rm...@emforium.com>.
Bruno Busco wrote:
>
> 2010/5/2 Scott Gray <sc...@hotwaxmedia.com>
>
>> 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?
>>
>
> What about "overrides" ?
>
When i first read of the feature I felt "override" was appropriate because
the original use case was defined in terms of overriding a view-map entry.
But (without looking at the implementation) I think you could use this as an
extension as well ... for example, you could likely provide a new
view-handler (extension) to go along with an override view-map, and that
newly rendered form could postback to a new request-map (extension). So I
understand why Scott felt "extend" was the right term ...
I wonder if this is really just external modification to a controller.
Terms that felt kinda close were stuff like application,
external-definition, enhance ... perhaps something in that ballpark could be
used to define exactly what is happening here ?
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Controller-Injection-tp2076418p2123369.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Controller Injection
Posted by Bruno Busco <br...@gmail.com>.
2010/5/2 Scott Gray <sc...@hotwaxmedia.com>
> 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?
>
What about "overrides" ?
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 4/05/2010, at 8:02 AM, Bruno Busco wrote:
> Hi Scott,
>
> 2010/5/3 Scott Gray <sc...@hotwaxmedia.com>
>
>> 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
Re: Controller Injection
Posted by Bruno Busco <br...@gmail.com>.
Hi Scott,
2010/5/3 Scott Gray <sc...@hotwaxmedia.com>
> 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 <sc...@hotwaxmedia.com>
> >
> >> 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 <sc...@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
> >>>
> >>
> >>
>
>
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 <sc...@hotwaxmedia.com>
>
>> 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 <sc...@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
>>>
>>
>>
Re: Controller Injection
Posted by Bruno Busco <br...@gmail.com>.
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 <sc...@hotwaxmedia.com>
> 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 <sc...@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
> >
>
>
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 <sc...@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
>
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 <sc...@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
Re: Controller Injection
Posted by Bruno Busco <br...@gmail.com>.
What I remembered to have discussed about is actually here:
https://issues.apache.org/jira/browse/OFBIZ-3373
-Bruno
2010/5/2 David E Jones <de...@me.com>
>
> Just read this... I guess Bruno is thinking along the same lines.
>
> -David
>
>
> On May 2, 2010, at 12:04 AM, 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 <sc...@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
>
>
Re: Controller Injection
Posted by David E Jones <de...@me.com>.
Just read this... I guess Bruno is thinking along the same lines.
-David
On May 2, 2010, at 12:04 AM, 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 <sc...@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
Re: Controller Injection
Posted by Bruno Busco <br...@gmail.com>.
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 <sc...@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
Re: Controller Injection
Posted by Scott Gray <sc...@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
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 1/05/2010, at 3:56 AM, Adam Heath wrote:
> 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.
>
> <webapp> should be defined separately from the mount point it is
> attached too. Not all in one as it is now.
>
> Then, we could extend the webapp, or add more mappings on other servers.
Well you can sort of already do that, multiple webapps can point to the same webapp directory. The problem right now is that it doesn't support component notation so you'd have to do something like:
<webapp location="../../applications/order/webapp/ordermgr" ...
Regards
Scott
Re: Controller Injection
Posted by Adam Heath <do...@brainfood.com>.
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.
<webapp> should be defined separately from the mount point it is
attached too. Not all in one as it is now.
Then, we could extend the webapp, or add more mappings on other servers.
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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.
Regards
Scott
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 30/04/2010, at 5:07 PM, David E Jones wrote:
> On Apr 29, 2010, at 10:12 PM, Bob Morley wrote:
>>
>>
>> Scott Gray-2 wrote:
>>>
>>> What about adding something like the following to ofbiz-component.xml
>>> schema
>>> <extend-web-app name="order"
>>> include-controller="path/to/controller.xml"
>>> />
>>>
>>> This would basically be similar to the "include" element available in the
>>> controller schema except that it would override any elements in the
>>> web-app's normal controller.
>>>
>>> Doing this would allow us to externally override any requests and views in
>>> a base application's controller without needing to completely replace the
>>> existing webapp and could be a good starting point for building "plug-in"
>>> support.
>>>
>>> Say for example you simply want to make a few changes to the EditProduct
>>> screen, you could just override the view-mapping to point to a screen in
>>> your custom component and boom, you're done.
>>>
>>
>> I really like the concept. Building on this, two variances for your
>> consideration came to mind ...
>>
>> <request-map webapp-name="partymgr" uri="EditParty"> ...
>> <view-map webapp-name="partymgr" name="EditParty" type="view" ...
>>
>> OR a new element ...
>>
>> <controller-override webapp="partymgr">
>> [standard request & view maps elements]
>> </ ...
>>
>> This came from a perceived desire to be more granular in what I override in
>> another application. The other is to be able to separate out my "overrides"
>> from my standard controller. ie. I could see having a controller.xml and a
>> controller-override.xml (where controller.xml includes override).
>>
>> The other thought is maybe consider a "global" definition -- I believe
>> services does there service definitions are in general global, but the
>> infrastructure is in place to have a local set of services (I think it keeps
>> two maps and looks in "local" for your dispatcher first). If memory
>> services, there are not examples of this usage in OOB Ofbiz mind you.
>> Naturally name collisions become a real consideration with this type of
>> thing ...
>>
>> PS. You can see I used "override" instead of "extend" because it seem more
>> clear to me what it was doing.
>
> The nice thing about Scott's suggestion is you have to do less file scanning and loading to find out that there are extensions/overrides. One thing I've thought for a long time is that it would be nice to not have to load so much just to get things running, ie do more lazy loading in the framework. Right now widgets are lazy-loaded, but that's it (entities, services, controllers, etc are all loaded on startup for every component and webapp).
>
> In Moqui this is a little easier as there is no controller.xml and instead request mapping and transitions out of screens are part of the screen definitions. To help avoid having to preload everything on startup (and enable more lazy loading) I put external subscreen (menu items, requests, etc rolled into one) extensions and overrides in the database. That may seem crazy, but in Moqui it is more of a general trend with configurable screens and forms where you still define them in XML, but there are certain changes users can do on the fly through the database, changes that are targeted at a less technical audience but still providing some flexibility.
I've been having a lot of similar thoughts lately about increasingly the runtime flexibility of the view layer and this sounds like interesting stuff, I'll definitely have to have a look and see what ideas can be stolen :-)
> In OFBiz some of these concepts may be useful. There are already some database driven things in the framework, and it might work for this too. I don't know if it's really possible at this point with OFBiz, but I'd rather move toward more lazy-load-ability rather than away from it.
Maybe I'm naive but I really don't think there is any move that is too bold to make if it is going to deliver significant improvements. I really couldn't care less about backwards compatibility if it starts to significantly hinder our ability to move forward.
Regards
Scott
Re: Controller Injection
Posted by David E Jones <de...@me.com>.
On Apr 29, 2010, at 10:12 PM, Bob Morley wrote:
>
>
> Scott Gray-2 wrote:
>>
>> What about adding something like the following to ofbiz-component.xml
>> schema
>> <extend-web-app name="order"
>> include-controller="path/to/controller.xml"
>> />
>>
>> This would basically be similar to the "include" element available in the
>> controller schema except that it would override any elements in the
>> web-app's normal controller.
>>
>> Doing this would allow us to externally override any requests and views in
>> a base application's controller without needing to completely replace the
>> existing webapp and could be a good starting point for building "plug-in"
>> support.
>>
>> Say for example you simply want to make a few changes to the EditProduct
>> screen, you could just override the view-mapping to point to a screen in
>> your custom component and boom, you're done.
>>
>
> I really like the concept. Building on this, two variances for your
> consideration came to mind ...
>
> <request-map webapp-name="partymgr" uri="EditParty"> ...
> <view-map webapp-name="partymgr" name="EditParty" type="view" ...
>
> OR a new element ...
>
> <controller-override webapp="partymgr">
> [standard request & view maps elements]
> </ ...
>
> This came from a perceived desire to be more granular in what I override in
> another application. The other is to be able to separate out my "overrides"
> from my standard controller. ie. I could see having a controller.xml and a
> controller-override.xml (where controller.xml includes override).
>
> The other thought is maybe consider a "global" definition -- I believe
> services does there service definitions are in general global, but the
> infrastructure is in place to have a local set of services (I think it keeps
> two maps and looks in "local" for your dispatcher first). If memory
> services, there are not examples of this usage in OOB Ofbiz mind you.
> Naturally name collisions become a real consideration with this type of
> thing ...
>
> PS. You can see I used "override" instead of "extend" because it seem more
> clear to me what it was doing.
The nice thing about Scott's suggestion is you have to do less file scanning and loading to find out that there are extensions/overrides. One thing I've thought for a long time is that it would be nice to not have to load so much just to get things running, ie do more lazy loading in the framework. Right now widgets are lazy-loaded, but that's it (entities, services, controllers, etc are all loaded on startup for every component and webapp).
In Moqui this is a little easier as there is no controller.xml and instead request mapping and transitions out of screens are part of the screen definitions. To help avoid having to preload everything on startup (and enable more lazy loading) I put external subscreen (menu items, requests, etc rolled into one) extensions and overrides in the database. That may seem crazy, but in Moqui it is more of a general trend with configurable screens and forms where you still define them in XML, but there are certain changes users can do on the fly through the database, changes that are targeted at a less technical audience but still providing some flexibility.
In OFBiz some of these concepts may be useful. There are already some database driven things in the framework, and it might work for this too. I don't know if it's really possible at this point with OFBiz, but I'd rather move toward more lazy-load-ability rather than away from it.
-David
Re: Controller Injection
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 30/04/2010, at 4:12 PM, Bob Morley wrote:
>
>
> Scott Gray-2 wrote:
>>
>> What about adding something like the following to ofbiz-component.xml
>> schema
>> <extend-web-app name="order"
>> include-controller="path/to/controller.xml"
>> />
>>
>> This would basically be similar to the "include" element available in the
>> controller schema except that it would override any elements in the
>> web-app's normal controller.
>>
>> Doing this would allow us to externally override any requests and views in
>> a base application's controller without needing to completely replace the
>> existing webapp and could be a good starting point for building "plug-in"
>> support.
>>
>> Say for example you simply want to make a few changes to the EditProduct
>> screen, you could just override the view-mapping to point to a screen in
>> your custom component and boom, you're done.
>>
>
> I really like the concept. Building on this, two variances for your
> consideration came to mind ...
>
> <request-map webapp-name="partymgr" uri="EditParty"> ...
> <view-map webapp-name="partymgr" name="EditParty" type="view" ...
Well what I could do is just make include-controller a child element and allow more than one entry, then you can just put your requests in one and the views in the other (if your that way inclined).
> OR a new element ...
>
> <controller-override webapp="partymgr">
> [standard request & view maps elements]
> </ ...
Not 100% sure what you mean there.
> This came from a perceived desire to be more granular in what I override in
> another application. The other is to be able to separate out my "overrides"
> from my standard controller. ie. I could see having a controller.xml and a
> controller-override.xml (where controller.xml includes override).
Not entirely sure I follow you there, the existing model whereby you replace the legacy webapp with a new one from hot-deploy does what you describe above i.e. it only contains your modifications to the original because you use include-controller and then only override what you need to.
> The other thought is maybe consider a "global" definition -- I believe
> services does there service definitions are in general global, but the
> infrastructure is in place to have a local set of services (I think it keeps
> two maps and looks in "local" for your dispatcher first). If memory
> services, there are not examples of this usage in OOB Ofbiz mind you.
> Naturally name collisions become a real consideration with this type of
> thing ...
I wasn't aware of services having that capability, I'll have to look into it sometime as it sounds interesting. But back to the point, I'm not entirely sure I understand what a global definition would mean from controller entries?
> PS. You can see I used "override" instead of "extend" because it seem more
> clear to me what it was doing.
To me override means to "replace" whereas extend means "inherit and alter", the latter feels clearer to me since it is much more analogous to extending a class then it is to overriding a method.
Regards
Scott
Re: Controller Injection
Posted by Bob Morley <rm...@emforium.com>.
Scott Gray-2 wrote:
>
> What about adding something like the following to ofbiz-component.xml
> schema
> <extend-web-app name="order"
> include-controller="path/to/controller.xml"
> />
>
> This would basically be similar to the "include" element available in the
> controller schema except that it would override any elements in the
> web-app's normal controller.
>
> Doing this would allow us to externally override any requests and views in
> a base application's controller without needing to completely replace the
> existing webapp and could be a good starting point for building "plug-in"
> support.
>
> Say for example you simply want to make a few changes to the EditProduct
> screen, you could just override the view-mapping to point to a screen in
> your custom component and boom, you're done.
>
I really like the concept. Building on this, two variances for your
consideration came to mind ...
<request-map webapp-name="partymgr" uri="EditParty"> ...
<view-map webapp-name="partymgr" name="EditParty" type="view" ...
OR a new element ...
<controller-override webapp="partymgr">
[standard request & view maps elements]
</ ...
This came from a perceived desire to be more granular in what I override in
another application. The other is to be able to separate out my "overrides"
from my standard controller. ie. I could see having a controller.xml and a
controller-override.xml (where controller.xml includes override).
The other thought is maybe consider a "global" definition -- I believe
services does there service definitions are in general global, but the
infrastructure is in place to have a local set of services (I think it keeps
two maps and looks in "local" for your dispatcher first). If memory
services, there are not examples of this usage in OOB Ofbiz mind you.
Naturally name collisions become a real consideration with this type of
thing ...
PS. You can see I used "override" instead of "extend" because it seem more
clear to me what it was doing.
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Controller-Injection-tp2076418p2076487.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.