-
Notifications
You must be signed in to change notification settings - Fork 43
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
Generic filters #27
Comments
As an alternative to the solution proposed by @petrsvihlik , it could be implemented in the following simple way:
Like so:
Then, the signature of the existing constructors in covariant classes could be changed to accept Optional: We can enhance such code to also support our own Delivery SDK types (as mentioned in the table in https://forums.kenticocloud.com/discussion/31/strong-types-explained-code-generator/). Developers could then easily use e.g. the |
but we're open to any solutions...as long as they are backward compatible... :) |
I appreciate your effort, this issue has been mentioned several times and it should be resolved. However, we should not care about implementation yet, I consider API design and usage patterns more important. For Kentico developer the most important feature is to be able to easily discover what options are there. Let's admit it, IntelliSense is the primary way of finding out what the API can do. The suggested approaches share the same weak spot – API does not tell you, which types of values can be used. Moreover, you can get wrong results when a value of unsupported type is converted to a string. I propose a single solution – overloading methods. Just declare the relevant methods several times for each type that Delivery API supports. This way it will be very easy to see what types of parameters I can use and also it will be very difficult to make a mistake. |
One possibility is to go even further and create some sort of 'query' builder where intellisense can also show you what filters you can use. This way you don't need to remember that you need to use 'ElementsParameter' or 'GreaterThenFilter' as you would just see all options available to you directly.
It can be easily extended in future with other configurations/parameters. However, its obviously not backwards compatible and it would require major changes or a set of completely new methods. This could be partially solved by implementing the |
This problem will be solved in a new issue: #119 |
Current situation:
When I want to use e.g.
GreaterThanFilter
withDateTime
I have to know how to format theDateTime
so that the API accepts it.Proposed solution:
We should solve this in a generic way. The filters should accept
<T>
as a value and handle the formatting internally based on the type.public abstract class Filter
(the base class for filters) should be switched into a generic class<T>
and storing it in a public propertypublic string Value
should be modified to take the type into considerationDateTime
it should format it to the ISO 8601 format (accepted by the delivery API)ToString()
Filter
correspondingly (where it makes sense)Suggestions for any better approaches appreciated!
The text was updated successfully, but these errors were encountered: