[Koha-bugs] [Bug 19234] Add query parameters handling helpers

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19234

--- Comment #28 from Tomás Cohen Arazi <tomascohen at 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.