Smart Charging - SetChargingProfile object and data types

[LiorBenAri]

No description provided.

[YuriyDurov]

Hello @LiorBenAri! This PR looks great, I just have a small issue with a part of it:

OCPI.Net uses contract validators for validating the presense of properties instead of marking properties as required in the contract model. Normally, we define all contract properties as nullable and then use contract validators to check whether a property was null or not. This approach allows us to better distinguish between null vs default values (like 0 for numbers) in incoming data, and also allows us to better form validation error messages in case if some properties did not satisfy the protocol requirements. It also allows us to better validate things like arrays (at least one item present, etc.) and define other specific validation rules.

Can we have this PR updated so that it would not define required properties in contract models but would use validators to check for null values instead?

Here is some OCPI.Net documentation on this topic

And Validators code is located under src/OCPI.Net.Validation/Validators

[LiorBenAri]

Hello @LiorBenAri! This PR looks great, I just have a small issue with a part of it:

OCPI.Net uses contract validators for validating the presense of properties instead of marking properties as required in the contract model. Normally, we define all contract properties as nullable and then use contract validators to check whether a property was null or not. This approach allows us to better distinguish between null vs default values (like 0 for numbers) in incoming data, and also allows us to better form validation error messages in case if some properties did not satisfy the protocol requirements. It also allows us to better validate things like arrays (at least one item present, etc.) and define other specific validation rules.

Can we have this PR updated so that it would not define required properties in contract models but would use validators to check for null values instead?

Here is some OCPI.Net documentation on this topic

And Validators code is located under src/OCPI.Net.Validation/Validators

Hi Yuri,

Will edit as you requested.

Lior

[LiorBenAri]

Hello @LiorBenAri! This PR looks great, I just have a small issue with a part of it:
OCPI.Net uses contract validators for validating the presense of properties instead of marking properties as required in the contract model. Normally, we define all contract properties as nullable and then use contract validators to check whether a property was null or not. This approach allows us to better distinguish between null vs default values (like 0 for numbers) in incoming data, and also allows us to better form validation error messages in case if some properties did not satisfy the protocol requirements. It also allows us to better validate things like arrays (at least one item present, etc.) and define other specific validation rules.
Can we have this PR updated so that it would not define required properties in contract models but would use validators to check for null values instead?
Here is some OCPI.Net documentation on this topic
And Validators code is located under src/OCPI.Net.Validation/Validators

Hi Yuri,

Will edit as you requested.

Lior

I see that there isn't a validation logic for all of the library objects (for example Session\CDRs objects).
Do you consider adding validation logic for the ChargingProfile objects as mandatory?
Anyway we won't use the OcpiValidate mechanism because it doesn't fit our needs -

1. I'm not a fan of throwing exceptions, I prefer handling errors gracefully.
2. We aren't working with the OCPI HTTP API, hence such validation that throws error back to the client isn't useful for us.
   Maybe I've explained that to you in the past - we are developing an integration service between a OCPI service to a OCPP service, and we are working with Message Broker mechanism for that, so throwing validation exceptions doesn't fit that mechanism of ours.

Lior

[YuriyDurov]

@LiorBenAri Sure, it is not required to add validation logic right now, it can always be added later. Thank you for adding the contract models. Just make sure you have some other way in your project to check if those fields are present in the incoming data.

Regarding OcpiValidate method and OCPI HTTP API: You are not forced to use OcpiController class or it's OcpiValidate method. The package was built to be modular and you can use some parts without using others. You can use validators without using controllers - just resolve the validator directly from your DI container, and call it's Validate method. This method will return a validation result and not throw exceptions. You can then decide what to do with this result yourself. The validation result is built by the FluentValidation package.

Thank you for pointing out some other validators are missing, too. I will try to add those later if I can. The package is far from perfect and does require some work in order for it to become feature-complete.

This looks great. I am merging this.

[LiorBenAri]

Thank you Yuri.
I like you to know that the package is great and it is super helpful for us for our OCPI development!

[LiorBenAri]

@YuriyDurov
You gonna publish a new version of the package with this last changes?

[YuriyDurov]

@LiorBenAri Yes it's published, the new package version is 0.16.2 and it contains these changes.

And thank you for the kind words :)

[LiorBenAri]

Thank you :)