http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6427
--- Comment #31 from Kyle M Hall <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
