Victor - Thank you for the prompt response. Great points, indeed. Yes, absolutely. We are committed as an organization to contributing to open source. We are in a very early stage of adopting fineract and still learning. Will definitely raise PRs for the changes that we make. The only concern was that all such changes might not be helpful to larger community. But I guess it is better to suggest those changes and see if they are incorporated/merged.
James, thanks for throwing light on design approach. Build "on-top-of" is exactly what I am looking for. I was exploring to see if I could add new handlers or use custom drop-in classes by implementing existing interfaces but wasn't sure if this approach was the right one. Will check for the "drop-in" approach to extend functionality. On Wed, Jan 11, 2023 at 10:16 AM James Dailey <[email protected]> wrote: > Those are good comments Victor. Absolutely! > > Shashwat - > In that vein… We also must have a design approach that isn’t “strongly > typed” to a single institutional set of requirements. When modeling a > design change, gather all of related use cases so that it’s a truly > valuable contribution. > > I’m addition, one of our goals we have as a project is to make it possible > for specific implementations to build “on-top-of”. There was mention of a > Java class “drop in” strategy in I think version 1.7? (Whereby core > release remains but you can instantiate specific “over rides” ). Search the > archives for that. That may answer, but only under certain circumstances. > It was imagined as a way to “extend” existing functionality. We should > make sure that gets documented. > > > > On Tue, Jan 10, 2023 at 8:11 PM VICTOR MANUEL ROMERO RODRIGUEZ < > [email protected]> wrote: > >> If the organization is committed to open source, modify it and send it >> back to the community as PR, best practices and debate will go to the >> source code itself. By experience if you go to implement a new big feature >> or vice versa a small change, anyone in the community will implement it and >> then the code in the source code could be refactored leaving your code with >> conflicts or hard to upgrade, i.e. today morning someone was facing an >> issue about the MySQL/MariaDB database creation and now the PR is ready to >> be reviewed/merged. For sure it is better to send back the changes and >> receive feedback as soon as possible. >> >> If your organization has a lot of FTE working on new features, changes, >> improvements in your fork/branch... the same proportional effort (most of >> the time, effort is measured in hours) will be invested to do the >> merge/upgrade to a new Apache Fineract release. >> >> If there are intellectual property reasons or limitations by a regulator >> or authority then... create a plugin or another external microservice >> without touching the code base. I have written a lot of "if" because of a >> lack of details about the roadmap of your implementation. >> >> You can look at https://www.apache.org/theapacheway/ >> >> El mar, 10 ene 2023 a las 21:27, Shashwat Srivastava (<[email protected]>) >> escribió: >> >>> Hi everyone, >>> >>> I have been going through the Fineract codebase for our organization >>> recently. And I had a fundamental question. If I want to customise specific >>> behaviour, for instance, add a new allocation priority order or change how >>> the repayment schedule is generated. Is there a recommended way of doing >>> such customisations to ensure that you don't modify the original codebase? >>> Is there any documentation around this? Please share. >>> >>> Cheers, >>> Shashwat >>> >>> >> -- > Sent from Gmail Mobile > -- Shashwat Srivastava
