-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
Hello :) The repositories are already interfaces. The repositories' implementation you probably saw are just samples in the 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 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 :) |
Thank you @lilgallon for the nice and quick answer. It is clear.
because as I see for example |
No problem, yes
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) |
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?
The text was updated successfully, but these errors were encountered: