You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Shashwat Srivastava <da...@gmail.com> on 2023/01/11 03:26:46 UTC
Best practices to customise Fineract codebase
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
Re: Best practices to customise Fineract codebase
Posted by Ed Cable <ed...@mifos.org>.
Shashwat,
In case you didn't find it on the list. There is some documentation on the
"drop-in" approach to extend functionality by overriding default services
with custom services via our custom modules which Aleks had been working
on::
https://fineract.apache.org/docs/current/#_custom_modules
Ed
On Tue, Jan 10, 2023 at 9:13 PM Shashwat Srivastava <da...@gmail.com>
wrote:
> 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 <ja...@gmail.com>
> 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 <
>> victor.romero@fintecheando.mx> 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 (<da...@gmail.com>)
>>> 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
>
>
--
*Ed Cable*
President/CEO, Mifos Initiative
edcable@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
Re: Best practices to customise Fineract codebase
Posted by Shashwat Srivastava <da...@gmail.com>.
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 <ja...@gmail.com>
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 <
> victor.romero@fintecheando.mx> 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 (<da...@gmail.com>)
>> 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
Re: Best practices to customise Fineract codebase
Posted by James Dailey <ja...@gmail.com>.
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 <
victor.romero@fintecheando.mx> 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 (<da...@gmail.com>)
> 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
Re: Best practices to customise Fineract codebase
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
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 (<da...@gmail.com>)
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
>
>