We want to replace all the calls to constructors of model classes by using MTable.get(...).getPO(...). That allows to extend the model classes because getPO(...) uses OSGi plugins to decide which class will be created.
Hi i concern something relate to current IModelFactory and MClass design.
1. current just one implement of IModelFactory is pick up to use, so if you have two plug-in, both have difference concrete implement, just one is performance correct.
2. current cache implement at implement of IModelFactory, if developer of plug-in forgot it, you lost it.
current MClass have some role:
+ info class of DAO (mapping record to java object)
+ business tie
+ business class
+ validate tie
1. need to separate it, let override more easy
2. just Info class part need to cache.
about validate, current implement somewhere like callout, validate rule, MClass....
almost trigger by GUI, so hard to reuse (example import csv function need hack to reuse it)
maybe apply pattern decorator to MClass, so more plug-in with difference override can live together.
I agree with your point that Model class are too tidy with Business logic and many time needs to change core business logic which force us to modify core.
Solution may be we construct each doc action as configurable sequence of action. This action sequence may need to configure per implementation. My this argument sounds like adding support for business logic workflow support.
Pattern decorator may be one option if we dynamically able to configure sequence of action classes (Here is where all small business logic stays) but at end this design will be nasty in debugging for developers.
About your point regarding callout, purpose is completely different. Call out serve as defaulting logic or action based on value selected on screen. So Call out should be there as it is.
So if we look today, there is no clear solution presents untill we start do some POC and adopt one which can be accepted.
"configurable sequence of action" can achieve by some way
+ add more properties to component definition (now have only service rank)
+ define on database, let each plug-in add meta data into database
+ add method to IModelFactory for this purpose
but don't need consider that time.
Don't forget this is related to
I think this ticket is complementary with the other one.
Agree all above discussion should go to IDEMPIERE-2848.
But should we Initially take approach of 2849 as that is known and Think new approach for and finalize our design? I think will need POC for each approach and then we can select best fit.