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
[dev.icinga.com #11160] Please align URL capabilities to filters #2296
Comments
Updated by elippmann on 2016-02-18 11:35:42 +00:00
Hi Tom, Could please explain this in more detail. I don't know what you mean :) Best, |
Updated by tgelf on 2016-02-18 12:13:30 +00:00 We added for example case-sensitiveness and afair array matches or similar. I expect a test doing Filter::fromQueryString($handCraftedFilterObject->toQueryString()) to always build the very same original object, no matter in what way you built your $handCraftedFilterObject. Cheers, |
Updated by elippmann on 2016-02-18 14:04:31 +00:00 Do you have a quick example where this is not the case? |
Updated by tgelf on 2016-02-18 14:39:32 +00:00 We already slightly broke the rules with FilterMatch in #6557. A dedicated sign like the mentioned ~ has never been introduced, so FilterMatch renders like FilterEqual - no way to find back. That's not a problem, as they have been separated "for future improvements". But now we have FilterMatchNot, FilterMatchNotCaseInsensitive, FilterMatchCaseInsensitive - and I see no corresponding code that takes care of rendering / parsing of those. Additionally implemented filters should be supported in our most important filterable backends (DB, LDAP...). There is also magic array-handling support that should be defined and tested. If I correctly read the code 809861c (just an example) changed existing behaviour as it probably broke a=(b|c*). Please note that I didn't test this, but to me it looks like it returns too early to let the former logic happen. So there is either a bug or dead code to be removed. (but that's not what this issue is all about, I stumbled over that commit while researching for this answer). |
Updated by elippmann on 2016-02-19 15:25:53 +00:00
|
Updated by aklimov on 2016-12-22 09:18:17 +00:00
|
Updated by aklimov on 2016-12-22 14:13:21 +00:00
I think it would be better to rebuild the URL syntax completely to make it more "alignable". See the attached file for details. |
Updated by tgelf on 2016-12-22 15:27:36 +00:00 Replacing such a central component is not what this issue asked for. You do not build a new house when asked to paint it's windows, do you? Sorry, no way at this point. You might want to open a dedicated issue for your proposal. Filter parsing is used for URLs, restrictions, shared navigation filters, many places in Director and other modules. Good luck with migrating all of those. This issue should be fixed for our existing Filters, regardless of whether we implement five new better implementations or not. |
Updated by aklimov on 2016-12-22 15:44:00 +00:00
tgelf wrote:
No, but I feel free to suggest building a new house if this seems far easier than painting that paticular windows for me. That's what I did – no more and not less. (FYI: I even haven't written a single line of code for this proposal.) tgelf wrote:
Fine. #13741 tgelf wrote:
Who says "migrating"? aklimov wrote:
I could imagine that the old and new syntaxes can coexist even in the same filter. |
Updated by aklimov on 2016-12-22 15:44:06 +00:00
|
Interesting, thanks. So now that we can track that proposal in a dedicated issue, may I ask for the state of the of the original request? 👅 |
Nothing happened I guess :) |
Suggestion:
Additional ideas:
|
Since nothing happened after soon 5 years, we can forget about this I think. Though, it's not only that nothing has happened:
And since I'm about to implement an alternative to |
This issue has been migrated from Redmine: https://dev.icinga.com/issues/11160
Created by tgelf on 2016-02-15 11:31:39 +00:00
Assignee: (none)
Status: Feedback
Target Version: Backlog
Last Update: 2016-12-22 15:44:00 +00:00 (in Redmine)
We introduced technical debt by implementing filter capabilities with no matching URL rendering rules. We must bring our filters back to a state where all of them can be rendered to and parsed from URL strings. We should also take care that most of our data providers using filters are able to render/understand all filter capabilities.
Cheers,
Thomas
The text was updated successfully, but these errors were encountered: