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

Question on the validation of objects #107

Open
TohidHeshmati opened this issue Jun 3, 2024 · 3 comments
Open

Question on the validation of objects #107

TohidHeshmati opened this issue Jun 3, 2024 · 3 comments
Labels
discussion Further information is requested

Comments

@TohidHeshmati
Copy link

I read through the doc and a bit through this library. I have two questions regarding the usage before contributing to it:
1- why the repository is included? shouldn't the library leave it out to user how they use it and just use it as an interface to communicate? (same question goes for the http client but having that makes more sense of course)
2- why not validation on objects are happening in the first place? so if a field is defined with specific criteria (length for example must be 16 or it must follow specific regex pattern) why not adding those restriction on the object fields?

@lilgallon lilgallon added the discussion Further information is requested label Jun 3, 2024
@lilgallon
Copy link
Member

lilgallon commented Jun 3, 2024

Hello :)


The repositories are already interfaces. The repositories' implementation you probably saw are just samples in the test source set. This lib only provides code that is OCPI dependent.

I may have misunderstood your question, so if it is about the fact that the library has some business logic, here is the answer:

We could have made a library only providing interfaces based on what is defined in the OCPI protocol. We wanted to take it a step further and implement all OCPI related behavior so that when we use it in a project, it works out of the box. The only thing for the user to implement is what is not OCPI-dependant (how to retrieve objects, how to make HTTP calls, and so on). That way, for example if you need the locations module, you just need to implement your HTTP server and how to retrive / update locations objects and it works.

Even if the users want to do everything themselves, it is possible by only using the provided interfaces and ocpi objects. But in that case I guess that users do not need a lib for it as implementing interfaces themselves would give them more freedom if something has to be updated


It is to allow users to opt-out of validation. In many real cases, some partners do not respect 100% of OCPI validation, but we still have to communicate with them. We want to give users control on what they allow or not. If they want to enforce validation, they can, but it is not a must-have. If the validation were to be directly on object fields, users would have no choice but to respect OCPI validation to instantiate OCPI objects

I hope I was clear enough :)

@TohidHeshmati
Copy link
Author

Thank you @lilgallon for the nice and quick answer. It is clear.
one last thing: what do you mean by:

how to retrieve objects, how to make HTTP calls, and so on

because as I see for example LocationsEmspClient is there and implemented. does that mean that is up to user to if use this or their own http client?

@lilgallon
Copy link
Member

No problem, yes LocationsEmspClient is there and implemented, but takes some parameters in its constructor:

  • transportClientBuilder: implemented by the user that specifies how to make HTTP calls
  • serverVersionsEndpointUrl: identifier for the partner (/versions url of partner)
  • partnerRepository: implemented by the user, it's the repository that holds all the information about OCPI Partners (endpoints, tokens, ...)

It builds an HTTP request that respect OCPI protocol and parses response following OCPI protocol. It is the only thing it does. Then it's up to the user to define the rest (including how to actually perform HTTP request)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants