I try to write down some ideas I have on how I would like add-on modules in OFBiz.
-- Add-on module management -- Every module should have a name, a version, a description, an author etc. Every module should have a list of modules from which it depends. A module should be added to the system using an add-on manager application. The add-on manager should be able to list all the modules installed with their version and dependencies. The add-on manager should let a module installation (or activation) only if all other required modules are installed and activated. -- Module integration -- An "administration" application should be used to set all configurations for all the modules (core and add-on). The configuration fields or fieldgroups for all the modules should be added to the admin configuration screens. Additional modules, when added to the system, should be able to add new features into other, pre-existent modules without requiring the pre-existent modules to be aware of them. Example: In the catalog application, when looking at a product, there is a button that allows to go to the ecommerce page for that product. This is an example of how two applications are linked in a way that ties them toghether so that it is not possible to install one without the other. The ecommerce application depends on the catalog but the other way around should not be. This ecommerce page link (not only this of course) is an example of the catalog dependence on the ecommerce that should not be. This ecommerce page link button should be, in some way, not implemented in the catalog application but in the ecommerce one. The catalog application should only allow a plug-in hosting features (hooks ?) that allows other applications to add links, fields etc. to the product page and in all other places. While looking at a party, there are links in the menu that go to "Shopping list", to "Employment applications", to "Billing and financial accounts", "Orders", "Quotes" and even "Geolocation". What happens if I want to use OFBiz to manage people that is not supposed to buy things but, for instance, doing something else? What happens if the users are not connected to the Internet and have no possibility to access the Googlemap for the Geolocalization? In these cases I would like to be able to disable (or not install) the Geolocalization, the orders, the accounting and the human resources modules. All the links should be automatically removed from the UI. I know that the entity, screen, form, menu extension system allows to have a new application that extends some other but what I think would be nice is a mechanism that allows a new application to change the behaviour of an "old" application (without changing its code). What about a system that allows to define a menu extension to a pre-existent menu? By this I mean that supposing to have an applicationA with a menuA, if I install an additional applicationB, this application is able to add a couple of menuitems to the menuA of the applicationA. And what about if this would be done on screens also? Thank you, -Bruno 2009/12/17 David E Jones <d...@me.com>: > > On Dec 17, 2009, at 3:46 PM, Bruno Busco wrote: > >> Having OFBiz splitted in a core framework and add-on modules seems to >> me like a must if we want to improve features. >> Add-on modules is how many large and popular projects are built. >> Even OpenERP says to have more that 350 modules and offers different >> flavours of it here http://www.openerp.com/discover/demonstration.html > > We already have a plugin, or add-on, or whatever you want to call it, > facility: components. > >> I think we should start discussing on the module add-on system that we >> want to implement in OFBiz. >> I have read that there is a plan from Neogia people to introduce what >> they have developed. Is there any schedule for this? >> Are you going to write a Confluence page where we can see how it works? >> >> Are we going to host the add-on modules on a separate SVN folder? > > It seems the whole point of add-on modules is to NOT have them be part of the > project. The intellectual property issues and concerns are totally different > from the main project, and the licensing may not be compatible with what the > ASF requires, so no I really don't think it would make sense to have a place > for more loosely managed stuff in SVN. > > On the other hand, we already have a place for add-on modules in SVN: the > specialpurpose directory. > > Consider that the framework and applications directories are the basis of > OFBiz, and everything else is an add-on of sorts. The applications are > important so that add-on components can use the common data model for > implicit integration, unless the add-on application won't be doing anything > with common business data, and then it only needs depend on the framework. > > Now getting back to the point... I think you already know all of this Bruno, > so what is it that you'd like to see that OFBiz does not already have? > > -David > > >> 2009/10/29 Tim Ruppert <tim.rupp...@hotwaxmedia.com>: >>> This sounds fantastic Marc - it's amazing to see many of the software >>> providers out there coming together to back this idea. This has the unique >>> opportunity of taking everything that OFBiz does to the next level. >>> >>> I guess the big question is, what's next to help get some of these backend >>> ideas back into this newly refined mission? We're more than happy to devote >>> resources to making this happen. >>> >>> Cheers, >>> Ruppert >>> -- >>> Tim Ruppert >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> o:801.649.6594 >>> f:801.649.6595 >>> >>> On Oct 29, 2009, at 7:47 AM, Marc Morin wrote: >>> >>>> As many of you know, we at Emforium have been busy building out a full set >>>> of business software application to provide an "ALL-IN" comprehensive >>>> solution for the small business market. When we started the evaluation >>>> over >>>> a year ago, Ofbiz was the selected platform of choice. Other components >>>> are >>>> Zimbra for email and concrete5 for web. >>>> >>>> Over this time, we've spent our efforts providing an entirely new UI front >>>> end for the backend applications: sales order, inventory, CRM, admin, >>>> reports, multi tenancy, published datasets (makes solution targeted for any >>>> market or geography), etc... >>>> >>>> We have expressed privately that Ofbiz needs to have a new mission in >>>> order to really drive it's importance and relevance as an open source >>>> project. As it stands, it's scope is very wide, and not targeted a >>>> providing and out-of-the box solution to any problem, save ecommerce (even >>>> then, lot's of styling work usually needed). >>>> >>>> We would be 100% behind this direction for Ofbiz. We'd want to contribute >>>> back components now that are Emforium proprietary and would work to reduce >>>> the amount of deviation between our proprietary solution and this newly >>>> stated direction. >>>> >>>> Marc >>> >>> > >
