[Koha-devel] Marseille16 / REST api

Thu Oct 13 01:52:02 CEST 2016

Hi Tomas,

It’s bug 10662, but I haven’t posted the revised patches with the parameter validation yet.

After reviewing bug 17425 and the documentation for Class::Exception, I see what you’re saying.

These two sections are the part that explain it for me best:

 <http://search.cpan.org/~drolsky/Exception-Class-1.40/lib/Exception/Class/Base.pm#MyException->throw(_$message_)> http://search.cpan.org/~drolsky/Exception-Class-1.40/lib/Exception/Class/Base.pm#MyException->throw(_$message_)

 <http://search.cpan.org/~drolsky/Exception-Class-1.40/lib/Exception/Class/Base.pm#$exception->message()> http://search.cpan.org/~drolsky/Exception-Class-1.40/lib/Exception/Class/Base.pm#$exception->message()

However, I think there’s still room for convention.

For instance:

try {

                $patron->blah('blah');

} catch {

                ok( $_->isa('Koha::Exceptions::Object::MethodNotFound'),

                'Calling a non-existent method should raise a Koha::Exceptions::Object::MethodNotFound exception' );

};

This is a basic example… I’d want to see “which” method was not found. Of course, Object.pm defines that in the exception:

Koha::Exceptions::Object::MethodNotFound->throw( "No method $method for " . ref($self) );

Koha::Exceptions::Object::PropertyNotFound->throw( "No property $p for " . ref($self) );

However, that’s more human readable than machine readable. Let’s say we’re doing a CRUD form for the web UI, and we have something like Koha::Exceptions::Object::ValueInvalid. I think we’d want an error code or error message that would be easy to catch in the code, and then we relay that to the template in a way which allows for translation. 

In my code, I’ve been doing it like in my .pm/.pl:

$errors->{url}->{invalid_scheme} = 1;

Then in the template:

[% IF ( errors.url.invalid_scheme ) %]

                Your url must start with http:// or https://

[% END %]

While my approach works, I don’t know that I’ve seen it elsewhere in Koha, and it just feels a bit… suboptimal to me. I don’t know why.

I suppose if I were using exceptions… it might be something like Koha::Exceptions::URI::InvalidScheme, and I’d probably be manually throwing that error in my processing of the CRUD form (since different forms might accept URIs with different schemes). I suppose in this case I don’t necessarily need the URI scheme that they did use… I just need to tell them the one that they “need to use” and I know that based on my controller’s logic and display it with the view. I suppose if they did use a scheme like “ftp”, I would know about it since I’m trying to catch that exception… and then pass it to the view if necessary.

So I guess in the end my questions are a bit irrelevant in terms of exceptions per se and relate to how we surface errors for users in a consistent way…

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: Tomas Cohen Arazi [mailto:tomascohen at gmail.com] 
Sent: Wednesday, 12 October 2016 6:17 PM
To: David Cook <dcook at prosentient.com.au>; koha-devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] Marseille16 / REST api

El mié., 12 oct. 2016 a las 7:26, David Cook (<dcook at prosentient.com.au <mailto:dcook at prosentient.com.au> >) escribió:

Really curious to see how this plays out!

I’ve just added parameter validation to a Koha::Object, and while it works well enough, I’m hoping for a more generalized solution. I haven’t looked at Koha::Exceptions::* yet, but maybe that will help.

I don't know how that would work, what bug number is it?

Peeking at Koha::Exceptions::MissingParameter, I hope that there’s more specificity than just “A required parameter is missing”. I’d want to know which required parameter is missing.

Is there a document somewhere saying how to use Koha::Exceptions?

Well, we are not baking our own exception system, we are just using Class::Exception so it is pretty documented!

Look at bug 17425, you will notice when we throw an exception we can add a message.

Regards!

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899 <tel:02%2092%2012%2008%2099> 

Direct: 02 8005 0595 <tel:02%2080%2005%2005%2095> 

From: koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org>  [mailto:koha-devel-bounces at lists.koha-community.org <mailto:koha-devel-bounces at lists.koha-community.org> ] On Behalf Of Tomas Cohen Arazi
Sent: Wednesday, 12 October 2016 2:39 AM
To: koha-devel <koha-devel at lists.koha-community.org <mailto:koha-devel at lists.koha-community.org> >
Subject: [Koha-devel] Marseille16 / REST api

During the first couple Hackfest days, Jonathan, Benjamin and I worked on a reference implementation of CRUD code for a REST endpoint, so others can read it, discuss it and use it as a reference for their own developments.

We worked on Koha::Cit(y|ies) because it was a really simple class. All our work is now on bug 17428.

The main goals/concepts we tried to apply were:

* Controller class (Koha::REST::V1::Cities) should be as simple as possible. No business logic on it. All business logic is expected to be put on the Koha::Cit(ies|y) classes. And fully tested.

* All verbs/use cases should be covered by tests (t/db_dependent/api/v1/cities.t). We did it, and this file could be used (with little adjustments) as the basis for new endpoint tests.

* Heavy use of exceptions. I wouldn't say we heavily use them, but the point is that we pass everything to the business object, and catch exceptions it might raise. Martin pointed out that he would help us further simplify it, making heavier use of the Swagger plugin's facilities. Specially on parameters sanity check. More on this tomorrow!

* Koha::Exceptions got per-class files so the exceptions file is more manageable. Bug 17425 introduced Koha/Exceptions/Object.pm, and we propose that's the way to go (Koha/Exceptions.pm still has Virtualshelves-related exceptions that should be moved).

* Make use of Try::Tiny for try/catch blocks. On the process we wrote bug 17425, which introduces new exceptions, we added the dependency for Try::Tiny (no worries, it is packaged for Jessie/Ubuntu) and Mirko was here to validate.

* Moving business-logic to Koha:: namespace and write REST endpoints on top of that business objects. We picked a simple object, Koha::Patron(s) will be a more complex one of course. This is what Jonathan has been doing, and people willing to write REST endpoints should check with him, and probably help moving business logic into Koha:: namespace.

There are several patches on bugzilla introducing endpoints. We will try to contact patch authors to help them make their work match this proposed 'guidelines'.

We are sticking to the 'patches speak' approach, so feel free to criticize this implementation, to improve it or even provide a counter-proposal. We are otherwise moving on, trying to get a functional complete REST api ASAP.

Thanks!

Tomas, Jonathan, Benjamin

-- 

Tomás Cohen Arazi

Theke Solutions (https://theke.io <http://theke.io/> )
✆ +54 9351 3513384 <tel:+54%209%20351%20351-3384> 
GPG: B2F3C15F

-- 

Tomás Cohen Arazi

Theke Solutions (https://theke.io <http://theke.io/> )
✆ +54 9351 3513384
GPG: B2F3C15F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20161013/d2af0dbb/attachment-0001.html>