Hello Everyone,
I have a proposal to make on how we could implement or rather start off with the Extension Architecture. While I have done a plugin system before, I don't currently know the internals of Adempiere well enough to the point where I could assuage that this works. Kindly go through it and let me/us know whether this could work.
I am going to assume that for an extension to be built into Adempiere, its has to have the following qualities:
(i)Use AD exclusively
(ii)Callouts through the scripting languages provided. (Not sure whether Workflow can be done in this. If not then check on (iv) below
(iii)Auto-Model Generation. This could be from the System Admin role where by clicking a button, all models could be generated.
(iv)Have a Module/Extension loader interface that specifies the jar file that includes all the files generated in the developer machine. This could be Models, and other associated jar files.
On the Adempiere side, every AD element that is defined would have to have a Module aspect that specifies which module that element belongs to. This would work the same was as customizations are either Dictionary / User Maintained etc.
By default, all items would belong to the module Core. Every extension would then have a pre-defined name. e.g AT HR and the customized parts in the AD are clearly marked that they belong to this module.
Based on this, a modified 2Pack can then be used to search for all "AT HR" elements in the AD, and pack those into a file, which with any jars can then be distributed.
Once modules are installed, they can only be upgraded or deactivated. I am not sure whether deleting, with all the referential integrity issues would be a good idea.would then have its related Modules.
This might just kick-start an elementary extension framework.
Regards
Ngigi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
* Auto generation of model is nice but to facilitate extension development I think we need to have utility that generate model interface for your extensions. This way, you can work with with your extension interface exclusively for columns that you have added to the standard model. The utility should probably also generate factory method that will adapt the standard model to your extension's interface.
* One of the biggest issue is the business logic that is embedded in the beforeSave and afterSave method of the standard model class. We need to find a solution to make this extensible/customizable.
Obviously I'm not against any of the proposals depicted here - just to let you know that we can manage some of those currently - not the best approach currently, but can be managed - and +1 for every piece of work that can make adempiere more extensible more easily (better preserving backward compatibility, or at least preserving/extending the AD approach that most people here love)
> * Module/Extension loader
As I understand this is very desirable - but at least we can deploy at this moment jar files in packages/lib directory or customization.jar and they'll be included in Adempiere.jar.
So, we could think currently we have a static loader (again, not the best approach, but is working currently)
> * Callout and ModelValidator
+1 and +1 - good to have these enhancements
Just to notice that this is not a stopper currently - meanwhile we can use the old approach, I used model validator in LCO (Localization Colombia) and I update the ad_client record like this:
UPDATE AD_Client
SET ModelValidationClasses =
CASE
WHEN ModelValidationClasses LIKE '%org.adempiere.model.LCO_Validator%'
THEN ModelValidationClasses
WHEN LENGTH (TRIM (ModelValidationClasses)) = 0 OR ModelValidationClasses IS NULL
THEN TO_NCHAR ('org.adempiere.model.LCO_Validator')
ELSE ModelValidationClasses || ';org.adempiere.model.LCO_Validator'
END
WHERE AD_Client_ID != 0
Again, great to have and +1 if we find it.
And again currently we can use a different approach - what we did in LCO is that we added new columns to core tables, but we don't need at all to generate model classes for core.
We just need to be sure that we use generic setters/getters from PO get_Value and set_CustomColumn
> beforeSave and afterSave method of the standard model class.
> We need to find a solution to make this extensible/customizable.
Well, again I think we have it currently.
In LCO when I needed to change behavior of core model classes I simply used the model validator to avoid touching the before/after Save triggers.
And I suppose this is the right approach - before/after save triggers must have just general purpose business logic, and specific local/custom/vertical logic must be separated in a modelvalidator
> The document and accounting engine needs serious work to make
> it more extensible.
Hello Everyone,
I have a proposal to make on how we could implement or rather start off with the Extension Architecture. While I have done a plugin system before, I don't currently know the internals of Adempiere well enough to the point where I could assuage that this works. Kindly go through it and let me/us know whether this could work.
I am going to assume that for an extension to be built into Adempiere, its has to have the following qualities:
(i)Use AD exclusively
(ii)Callouts through the scripting languages provided. (Not sure whether Workflow can be done in this. If not then check on (iv) below
(iii)Auto-Model Generation. This could be from the System Admin role where by clicking a button, all models could be generated.
(iv)Have a Module/Extension loader interface that specifies the jar file that includes all the files generated in the developer machine. This could be Models, and other associated jar files.
On the Adempiere side, every AD element that is defined would have to have a Module aspect that specifies which module that element belongs to. This would work the same was as customizations are either Dictionary / User Maintained etc.
By default, all items would belong to the module Core. Every extension would then have a pre-defined name. e.g AT HR and the customized parts in the AD are clearly marked that they belong to this module.
Based on this, a modified 2Pack can then be used to search for all "AT HR" elements in the AD, and pack those into a file, which with any jars can then be distributed.
Once modules are installed, they can only be upgraded or deactivated. I am not sure whether deleting, with all the referential integrity issues would be a good idea.would then have its related Modules.
This might just kick-start an elementary extension framework.
Regards
Ngigi
hi Ngigi,
* The EntityType field in AD can be use as the module name ( we have extend the length of the field partly to work toward this ).
* Module/Extension loader
- Instead of building our own, I think we should use a stable and proven extension framework, for e.g OSGI Equinox.
- http://sourceforge.net/tracker/index.php?func=detail&aid=1914016&group_id=176962&atid=879335
* Delete would be very difficult to implement, it is good enough if we can do activate/deactivate.
* Callout and ModelValidator
- http://sourceforge.net/tracker/index.php?func=detail&aid=1914013&group_id=176962&atid=879335
- http://sourceforge.net/tracker/index.php?func=detail&aid=1914018&group_id=176962&atid=879335
* Auto generation of model is nice but to facilitate extension development I think we need to have utility that generate model interface for your extensions. This way, you can work with with your extension interface exclusively for columns that you have added to the standard model. The utility should probably also generate factory method that will adapt the standard model to your extension's interface.
* One of the biggest issue is the business logic that is embedded in the beforeSave and afterSave method of the standard model class. We need to find a solution to make this extensible/customizable.
* The document and accounting engine needs serious work to make it more extensible.
- http://sourceforge.net/tracker/index.php?func=detail&aid=1755851&group_id=176962&atid=879335
* There is a wiki page that have touch on some of the extensibility issues
- http://www.adempiere.com/wiki/index.php/Extensions_Friendly_Proposal
Regards,
Low
Hi all,
Obviously I'm not against any of the proposals depicted here - just to let you know that we can manage some of those currently - not the best approach currently, but can be managed - and +1 for every piece of work that can make adempiere more extensible more easily (better preserving backward compatibility, or at least preserving/extending the AD approach that most people here love)
> * Module/Extension loader
As I understand this is very desirable - but at least we can deploy at this moment jar files in packages/lib directory or customization.jar and they'll be included in Adempiere.jar.
So, we could think currently we have a static loader (again, not the best approach, but is working currently)
> * Callout and ModelValidator
+1 and +1 - good to have these enhancements
Just to notice that this is not a stopper currently - meanwhile we can use the old approach, I used model validator in LCO (Localization Colombia) and I update the ad_client record like this:
UPDATE AD_Client
SET ModelValidationClasses =
CASE
WHEN ModelValidationClasses LIKE '%org.adempiere.model.LCO_Validator%'
THEN ModelValidationClasses
WHEN LENGTH (TRIM (ModelValidationClasses)) = 0 OR ModelValidationClasses IS NULL
THEN TO_NCHAR ('org.adempiere.model.LCO_Validator')
ELSE ModelValidationClasses || ';org.adempiere.model.LCO_Validator'
END
WHERE AD_Client_ID != 0
http://adempiere.svn.sourceforge.net/viewvc/adempiere/contributions/Localizations/Colombia/packages/LCO_Retenciones/dict/PackOut.xml?view=markup
> * Auto generation of model is nice
Again, great to have and +1 if we find it.
And again currently we can use a different approach - what we did in LCO is that we added new columns to core tables, but we don't need at all to generate model classes for core.
We just need to be sure that we use generic setters/getters from PO get_Value and set_CustomColumn
> beforeSave and afterSave method of the standard model class.
> We need to find a solution to make this extensible/customizable.
Well, again I think we have it currently.
In LCO when I needed to change behavior of core model classes I simply used the model validator to avoid touching the before/after Save triggers.
And I suppose this is the right approach - before/after save triggers must have just general purpose business logic, and specific local/custom/vertical logic must be separated in a modelvalidator
> The document and accounting engine needs serious work to make
> it more extensible.
This is the only one I consider a current stopper. To create a new document and make it POST we need to change core classes. I remember there is a FR from Heng Sin about, maybe this one:
http://sourceforge.net/tracker/index.php?func=detail&aid=1762470&group_id=176962&atid=879335
Regards,
Carlos Ruiz