Thank you Erwan for this clause-by-clause to the Neogia addon manager. To be sincere I was looking to something different from what seems to be a patch manager. I see that using patches is a solution that has no limit on what can be done. (A patch can be even a complete remake of an application). On the other hand since the patches can touch everything in the code they can easily be outdated when the code improves.
A module that plugs-in using specific "connectors" is more robust and it should work even if the code improves until the connectors remain unchanged (and in this case also connectors improvement may be compatible with old plugins). If I understand well (but please correct me if I am wrong) basing on SVN patches, the Neogia system should also be sensible on the repository the code has been checked-out from. What happens to OFBiz installation that is managed on a different SVN repository of even no SVN repo at all? -Bruno 2009/12/21 Erwan de FERRIERES <erwan.de-ferrie...@nereide.biz>: > Hi Bruno, > > here are some comments inline > > Le 19/12/2009 00:10, Bruno Busco a écrit : >> >> 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. > > The neogia addon management is using the same requirements you are talking > about and is already used and implemented. > The addon should use of the 3 types listed here : > application : only business rules and "classic" screens > framework : as named > specialpurpose : for a dedicated UI, for specifics or business rules in a > company (eg. the addon sales-adm-b2b is a specific interface which is using > standard OFBiz services, but relooked for the sales administration people in > a B2B environment). >> >> -- 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. > > We may start with all OFBiz components, a best pratice will be added in > addons. >> >> 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. > > This type of requirement is managed via one addon "catalog-ecommerce", which > is dependant from ecommerce and catalog. >> >> 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. > > Currently, some addons have been created and mandatory dependencies are > managed. The suggested ones are managed by hand. Adding a dedicated screen > is a good idea. >> >> 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? >> > Addons are now used since 6 months and this seems to be dependant from > addons. > What appeared during this 6 months is that : > * sometimes modifying existing files is more readable, > * one other time, using extends is better, > * another time, adding a component will be the solution, > * and sometimes, it's OFBiz which seems to be not enough modular... > > HTH, > >> Thank you, >> -Bruno >> > > ../.. > > -- > Erwan de FERRIERES > www.nereide.biz >
