Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for Dictionaries #10

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

Richard-Degenne
Copy link
Contributor

This PR adds basic support for TextRazor's dictionary features.

It adds 4 new endpoints to the API :

  • Creation of a dictionary;
  • Deletion of a dictionary;
  • Creation of dictionary entries;
  • Deletion of a dictionary entry.

The PR also revamps the way requests are handled, since until now, only the analysis API was considered.

@andhapp
Copy link
Owner

andhapp commented Dec 21, 2017

Hello @Richard-Degenne,

Nice to meet you!

Thanks for submitting a PR. I will look through it in a couple of days.

@Richard-Degenne
Copy link
Contributor Author

Hi @andhapp,

I added support for another endpoint of the dictionary API.

@Richard-Degenne
Copy link
Contributor Author

Any input on the current state of this PR?

@andhapp
Copy link
Owner

andhapp commented Jan 29, 2018

Sorry man!

It's been failing on Travis. I will have a look at it tonight. It must be something in the setup. I have glanced through the PR and it seems okay. Will look through it again just to make sure.

Thanks for your patience!

@Richard-Degenne
Copy link
Contributor Author

Yes, the Travis error seems unrelated, but I can't say for sure.

Thanks for your patience!

No worries. :)

@andhapp andhapp requested review from abrisse and andhapp January 29, 2018 15:30
README.md Outdated
#### Adding entries to a dictionary

```
entry = TextRazor::DictionaryEntry(id: 'my-entry', text: 'Text to be matched')
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DictionaryEntry and Dictionary should be internal classes, IMHO. The API interface should be something like this:

client = TextRazor::Client.new('api_key')
client.create_dictionary('my-dictionary') 
# This can have keyword arguments but I'd not do it if it's not anywhere else in the library, makes it inconsistent
client.create_dictionary_entries('my-dictionary', {id: 'my-entry', text: 'Text to be matched'})

These method calls create_dictionary and create_dictionary_entries should return the actual instances of Dictionary and DictionaryEntry but there is no need for the consumer to know how to create these instances. client hides that behind a facade and for a good reason.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'll rework these parts.

@@ -0,0 +1,36 @@
require 'rest_client'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the main reason to separate this out into an api_client class? `

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'll rework this part.

end

private

def self.build_query(text, options)
query = {"text" => text, "apiKey" => options.delete(:api_key)}
query = {"text" => text}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing it from here means this is not duplicated across 4 or 5 different methods. Any particular reason to do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The API key must be passed as a x-textrazor-key header.

As of today, this is not an issue because the only endpoint supported by the gem is a POST request, but adding support for dictionaries means supporting GET, PUT and DELETE requests.


module TextRazor

class ApiResponse
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to ApiRequest, Response class was meant to take care of this responsibility. Any particular reason to do this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Response class is heavily oriented towards parsing responses to analysis requests.

The more general ApiResponse can handle any kind of response from TextRazor. (Side note: Response inherits from ApiResponse)

@andhapp
Copy link
Owner

andhapp commented Jan 30, 2018

Hey @Richard-Degenne,

I had a look at the PR and left some comments on it.

@Richard-Degenne
Copy link
Contributor Author

Thanks for the review! I'm a bit snowed under at the moment, but I'll look into your remarks as soon as I have a moment.

@Richard-Degenne
Copy link
Contributor Author

Hi @andhapp,

It's been a while, but I intend to work on this PR in the coming days. I'll answer your reviews and rework some things here and there.

@Richard-Degenne
Copy link
Contributor Author

Hi @andhapp,

I rebased the branch onto master, took your remarks into consideration and cleaned my commit history.

@andhapp
Copy link
Owner

andhapp commented Apr 18, 2019

Thanks. I've reviewed your other PR. Will look at this one next.

@Richard-Degenne
Copy link
Contributor Author

Hi @andhapp,

Since the other PR got merged (thanks for that, btw), I rebased this one onto master and fixed the conflicts. Now, the dictionary support plays nice with the Europe endpoint support.

@Richard-Degenne
Copy link
Contributor Author

Hi @andhapp,

Any input on the current state of this PR? :)

@Richard-Degenne
Copy link
Contributor Author

Richard-Degenne commented Jun 10, 2019

Hi @andhapp,

Allow to bump. I understand you have some problems with GitHub notifications, so maybe this one will get through. 😛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants