Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(316)

Issue 29329521: Issue 3222 - Expose filter type as a string property (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
4 years, 1 month ago by Wladimir Palant
Modified:
4 years ago
Visibility:
Public.

Description

Issue 3222 - Expose filter type as a string property

Patch Set 1 #

Total comments: 2
Unified diffs Side-by-side diffs Delta from patch set Stats (+38 lines, -25 lines) Patch
M chrome/content/ui/filters-filterview.js View 2 chunks +2 lines, -14 lines 0 comments Download
M chrome/skin/filters.css View 1 chunk +5 lines, -3 lines 0 comments Download
M lib/filterClasses.js View 8 chunks +26 lines, -3 lines 0 comments Download
M lib/requestNotifier.js View 2 chunks +5 lines, -5 lines 2 comments Download

Messages

Total messages: 4
Wladimir Palant
4 years, 1 month ago (2015-10-29 19:41:52 UTC) #1
tschuster
On 2015/10/29 19:41:52, Wladimir Palant wrote: LGTM
4 years, 1 month ago (2015-10-31 13:03:58 UTC) #2
Thomas Greiner
LGTM Feel free to either reject the proposed approach or otherwise implement it in a ...
4 years, 1 month ago (2015-11-03 11:32:40 UTC) #3
Wladimir Palant
4 years, 1 month ago (2015-11-03 12:23:25 UTC) #4
https://codereview.adblockplus.org/29329521/diff/29329522/lib/requestNotifier.js
File lib/requestNotifier.js (right):

https://codereview.adblockplus.org/29329521/diff/29329522/lib/requestNotifier...
lib/requestNotifier.js:217: if (filterType != "elemhide" && filterType !=
"elemhideexception" && filterType != "cssproperty")
On 2015/11/03 11:32:40, Thomas Greiner wrote:
> Just a suggestion: What about introducing an `isException` boolean property in
> addition to the `type` property you introduced. That'd allow us to have a
common
> type for ElemHideFilter and ElemHideException that we can check for - similar
to
> how we currently check for ElemHideBase.
> 
> That'd allow us to keep checking filter inheritance at least to some extent
> without introducing too much overhead.

I think that would complicate things more than it would help. Right now there is
a 1:1 mapping between types and type strings, that's very straightforward. If
the type structure gets any more complicated we might want to think about type
identifiers like "elemhide:exception" and "elemhide:cssproperty" but I don't
think we are at a point where this would make sense.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld 87257f5