Extend Filter functionallity from #53 about simple-datatables HOT 7 CLOSED

Hey @Sysix
So, you have an interesting point. I believe that filtering by callback sounds like someone would expect from a filter.

With this in mind, I am thinking about a few points:

1. A filter is a Boolean function
2. The filter is hooked to column ( just like it is now )
3. The argument for the filter is the value in a cell.
   In the example, it would be either 'Assistant' or 'Manager'
4. The new set of rows is given by applying the filter to all the original initial rows, keeping those which the filter returns true.

And I have some remarks on that:

• Point 1 is the whole idea of function filters but I wonder how that would apply for the simple case, that is, how would the old example be implemented.

  Currently, once the row with a filter is clicked, we select only the rows whose cell value is the same as the filtered term. On the second click, we use the next term and finally, show all rows.

  In the example, it goes like this:

  All rows whose Job is Assistant → All rows whose Job is Manager → all_items → Assitant ...

  My question is, How do we handle functions as filters ? I have a few Ideas

  • Apply it on click, reset on next click.
  • Have a list of functions to be applied, similar to what we have now.
  • Apply it every time the user clicks the row
    On a side-note, This one seems to be the most straight-forward way but I feel that it puts more strain on the person that is using this library so that the provided function is able to change it's behaviour on every call and also be able to 'reset' and show all values again.

• Point 3 might be more useful if the callback had access to the entire row. This would enable us to write more interesting filters, for example, Administrator with .org emails.

Also, I see that on your example, you refer to the functions's arguments as colValue and colElement. What is the latter meant to represent ?

Hmm.. Looks like I wrote quite a bit.
I like the idea and I'd like your feed back on this feature.

from simple-datatables.

Thanks for your Feedback.

I agree to all points with you.

Also, I see that on your example, you refer to the functions's arguments as colValue and colElement. What is the latter meant to represent ?

colValue should be the innerText from the td-HtmlElement. The colElement should be the
td-HtmlElement itself.

To your question how we should handle the filters:

I would let the developer use it how he likes it. The filters and the config are filters which are applied at the start and can be removed via the method.
we should discuss how we get the filterId, maybe easy about a filterList property

The filters should be stackable. The developer need remove active filters manuelly.

Maybe as a Plugin we can create a Layout-Extension with predefined Buttons

from simple-datatables.

In the core,
When a user clicks in a header, first time, we apply the predicate.
On the second click, do we remove the predicate or apply the predicate again ?

from simple-datatables.

In the basic version no events should be set for the header or columns. Let the developer choice how he want to implement it

from simple-datatables.

For the events, you may hook something into https://github.com/fiduswriter/Simple-DataTables/wiki/Events#datatablesort
By default, this event is fired whenever you click the column.

from simple-datatables.

@johanneswilm Maybe you could close this ?

from simple-datatables.

ok

from simple-datatables.