Replies: 4 comments
-
Instead of trying to extend/replace the existing DateFilter, can't you just create your own filter implementing DateFilterInterface / using DateFilterTrait? |
Beta Was this translation helpful? Give feedback.
-
I don't see how that is a better solution. The My current workaround just removes a single word "final", which is a lot easier. Hence me asking: is there a good reason why |
Beta Was this translation helpful? Give feedback.
-
Well that's better because you don't have to overwrite code that doesn't belong to you - you could update api platform without breaking your version at all. And I don't know specifically why this one final, but it usually means your code shouldn't try to rely on its internal behaviour not changing. It follows that any changes of behaviour in future versions might actually not be what you want your version to do, which kind of nullifies your point about needing to update your version when the original changes - why change something that works for you? |
Beta Was this translation helpful? Give feedback.
-
I know I shouldn't be overwriting code that isn't mine. That's why I'm asking for the class to not be final, so that I wouldn't have to do that. You say I shouldn't rely on the internal behaviour of the code, but your solution is to literally copy the code into my own class, which is a contradiction. I don't want to rely on the internal behaviour of the code. I'm happy not to know what it does. It works. I trust that it works. If an update in the future changes the internal logic of that code, I'm OK with that and I'm happy for my code to use that updated logic. All I need is for that code to work with custom date types. This scenario is exactly what extending a class is for. To keep all the original logic, but change one little thing. Except that I can't, because it's marked as final, and I don't know why. If you insist that it should remain final for some reason, then fine. As an alternative, give me a method where I can append my custom date type to the list of allowed types. |
Beta Was this translation helpful? Give feedback.
-
Description
I would like DateFilter to work with my own custom DateTime types.
Example
I have an application that stores datetimes in multiple timezones (i.e. in some tables it is UTC, in another table it is local timezone). I can work with this by creating multiple custom DateTime types and registering them with Doctrine. I have these entities exposed in my API and I want to be able to sort by these fields. Unfortunately, the DateFilter class has a hardcoded list of types that it recognizes as being a date type, according to the isDateField method.
The logical solution here would be to create a new class that extends from DateFilter, customize it so the isDateField method returns true for my custom DateTime types, and use that new class in my ApiFilter. But the DateFilter class is marked as final, so I can't. Is there a reason why DateFilter needs to be final?
My workaround at the moment is to modify the DateFilter class to be not final, commit that change in my code, and I have to remember to do this every time I update Api Platform.
It would be nice if the DateFilter class wasn't marked final, or if there was some way to add custom DateTime types to its list of supported types.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions