Desinging the facade between backend controllers and the model

[UO289845]

Discussion about the desing and implementation of the facade that will comunicate the model with the backend controllers.

Daniel, Erdem and Jorge will do it, and Mario will revise it.

[UO289845]

At least there should be a method in charge of sending the answers to the backend. I believe this method should receive the id of the entity to generate the question from and in some way (maybe through a enum) the type of question. Thoughts on this?

To make myself clear. By the "id of the entity" I mean the literal Wikidata id. That's for example Q14317 for the entity of Oviedo. As I'm proposing this the backend should have the id's stored in some way (the storing mechanism is not actually relevant fot this and it should be done in the way those in charge of it (@Mister-Mario) see fit).

To dwell a bit deeper into the method, I think a valid option could be the following: List getAnwsers(String entity, QuestionType type)

[sinne10]

Would this method also return the question itself?

[UO289845]

In the original idea I had it did not return it. However, now that I rethanked it, I believe it's better if we do in fact give the question alongside the answers.

So now I think that a good idea could be the following: Question getQuestion(String entity, QuestionType type)

Since we are using Java it might be better to utilize an object instead of returning a list with all the options (hence why the return type). The facade class will only have this method, and the rest of the operations of the generation will be done apart from it (the hierarchy will be discussed either in a meeting or in an issue).

One of the reasons why I think that the class option is better than others is because it can include by itself the generation of the JSON (as detailed in issue #22) or just to give it all to the backend to compose it if preferable.

[Mister-Mario]

While I think that the Question type would be a useful parameter, I also think that only the question generator part knows and manages ids related to wikidata. On the other hand, I also think that as the backend will just return the question(s), maybe it is useful to have two methods 1 for a single questio, 1 for multiples one where client can specify the amount, it would be useful to already have the JSON formats, my idea would be to return always String so the part of the generator can do question.Json(), by doing this we decouple more the backend from this question generator in case we add more types of generators/games

[UO289845]

Ok, the method could return the JSON directly, no problem there. The problem I see is with the one question / multiple questions generation. I believe that the way the question generation module should work is by making a question whenever requested, while the app itself is the one who determines when the request should be done.

[Mister-Mario]

First, I understand that the String entity is also remove Second, while that would be a good aproach I think that you will acces other resources other than Wikidata when creating a question. If that the case maybe opening and closing that resource could imply time loss. On the other case, where you don't use any extra resource, there would be no problem, I think. Also de QuestionType could be useful but I would also like a random mode

[UO289845]

There's no way in which we could remove the entity parameter. For generating the questions we need to entity id, which should be stored in the backend, which coincidentally is the one who asks for the questions.

The way is supposed to work, is that the backend will select the entity from a collection of already predefined entities and ask for a type of question based on that entity. For example, for the entity Oviedo we might want a population question, so the method call could be something like getQuestion("Q14317", QuestionType.POPULATION);. The only other way I could potentially see is if instead of passing the entities id per se we passed the entity's name, but than name should also be stored in a similar fashion, and unless is a requirement I do not see any advantage in it.

Regarding the random type, no. To generate the questions wee need to parse the incredibly complex wikidata JSON file, and even though we can get different questions from a single entity like Oviedo (apart from the population we can get also the major in a chosen year, the amount of rain or lots of other things), if we move to a different type of entity, like a person (which did not have population, amount of rain of a major, but have a year and place of birth, for example) while possible, it adds such an unnecessary layer of complexity that is simply not worth it. Potentially, in a later stage we could given a set of potential question types to choose one at random between them.

And regarding the resources, nothing apart from Wikidata, don't worry. But also (just to make sure we're on the same page) there's no need to close the module and restart it for every question. Once the question is generated the module becames idle and does nothing until a question is requested again, but it probably could be open and closed again without any problem, I'll confirm you that once to module is finally designed.

[UO289845]

After the discussion during the meeting, the following design was reached:

String getQuestion(QuestionType type)

The id of the entity will be getted by the generator through the database so there's no need to passe it as a parameter. The question generation will return a Question object, which has a JSON method/attribute inside and the facade sends it using the toString() method to the output of the JSON.

[Mister-Mario]

Yes, that would be optimal