https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19234 --- Comment #28 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Julian Maurice from comment #27)
Maybe I'm missing the big picture here, but I don't understand why this plugin is needed. All it does is separate query parameters so one can pass 'reserved' parameters to others mojo helpers (at least that's how it's used in bug 19410), but helpers already have access to those parameters through their first parameter ($c), right ? And not all helpers will have a use for all reserved parameters, so passing all those parameters to all helpers is useless, they can retrieve what they need on their own.
Please explain :)
The idea behind this was: - To make sure some things are reserved and make it explicit. Have the list in a single place, make it grow if needed. - Make parameters extraction algorithm testable, so no need to add thousands of tests for each endpoint... and ... - Code less: we don't need to write useless repeating loops extracting parameters and separating the reserved ones on each controller method. Koha::Objects->search_for_api is a clear example of how this would improve productivity when writing endpoints. If you look at how a controller looks like using it when it is just a wrapper or Koha::Objects-derived classes, it becomes clear: sub list { my $c = ... my $objects = Koha::Blah->search_for_api($c); return $c->render( openapi => $objects, status => 200 ); } In this tiny example, pagination, sorting and query building choice are solved already using this helpers. And those who require more flexibility (business endpoints, that are not just wrappers to Koha::Object(s) derived classes) can just skip using them and do more interesting stuff. -- You are receiving this mail because: You are watching all bug changes.