[Koha-bugs] [Bug 6427] Rewrite of the accounts system

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427

--- Comment #31 from Kyle M Hall <kyle at bywatersolutions.com> ---
Sorry I missed this comment until now!

> 1/ Don't you think we should avoid calls to Koha::Database in pl files ?

Using DBIx::Class is, afaik, allowed in pl files. Requiring it to be called
from modules only just requires yet another layer of abstraction. The only time
this is necessary is when business logic needs to be applied. That is, we
should definitely keep code DRY by moving repeated chunks of code into a module
subroutine, but for a single line call that is not affected by system
preferences, this is both unnecessary and unwanted. It would merely slow the
system down.

For repeated pieces of code that utilize system preferences, I think they
*should* be in modules. Better yet, they should be part of the DBIx::Class
files, but we haven't gotten to that stage yet.

If I am violating my own person views written above, it's simply because I am
attempting to implement this new accounting system while making as few
modifications to existing code as possible. I think any violations will need to
be taken care of eventually. This is of course, assuming everyone else agrees
with my views. In any case, those violations can and should be taken care of
post-push once we have formalized our policies regarding usage of DBIC.

> 2/ Don't you think new module in the Koha namespace should be OOP (for ex.
> using Class::Accessor)?

Modules in the Koha namespace are not required to be OOP, and I can see no
advantage to making Koha::Accounts OOP. The data objects themselves are OO, and
Koha::Accounts is just a layer around these objects to manage them.

> 
> Outside the DBIx scope, I am wondering why do you have 2 scripts
> account_payment.pl and members/account_payment_do.pl. I suppose it is in
> order to remove the $op variable. I think it would be better to head towards
> a REST architecture. For example, here, we could imagine executing the
> AddCredit routine on a POST method and using the "show/list" view on a GET

That is certainly an interesting proposition. What advantages do you see to
this? I'd take it much further and say we should make *all* fetching, creating,
and updating of data be via REST methods, and make our scripts use those
methods via ajax. I think this will make Koha much more responsive, and allow
far more flexible integration with other software. What do you think?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are watching all bug changes.