Page MenuHomePhabricator

[MVVM] Model Composite Features
Open, WishlistPublic


To support user experience of model composite,
some additional model composite will be necessary.

  • Filter : filter the model child by given filter condition
  • Sort : composite model to sorted index by given sorting condition.

it may not properly works in big-data model,
so efl.range feature can help to restrict the condition.

This task is wishlist and lower priority than others.

SanghyeonLee triaged this task as Wishlist priority.
SanghyeonLee updated the task description. (Show Details)
SanghyeonLee added a subscriber: larryolj.
cedric added a subscriber: cedric.Nov 16 2018, 11:24 AM

What is efl.range ? I can only find efl.ui.range, and I don't think this is what you are talking about.

Sort needs to walk the entire model it is proxying in all case. We can make it work by having it remember a subset of the object it map and working by batch in the background. But be aware that there is always a trade off of speed vs memory use here. So I think we should put that as a parameter of the Model. To Sort you need to compare the object with other object. Either you keep all of them in memory and you are fast, or you only keep a cache of them as you insert object and remember a map of it.

For the case of filter, it is easier, we just need to remember the current object that is being filtered and we can discard it once we are done. We just need to remember the index that matter to us and update the total count. Easier to implement, I think.

One short coming that I don't think we want to address, if a property of a proxyed object used for sorting or filtering change, we might not be able to detect that in all case.

Also Sort and Filter model should be an interface and not just an implementation. Some model, like Eio or Boolean Model would be best to implement them directly.

SanghyeonLee added a comment.EditedNov 27 2018, 9:51 PM

well I was think to make it as an proxy model which can user "sort" or "filter" their original model.

for examples,

Orignal ModelSort Proxy ModelFilter Proxy Model (string "hy")

this proxy model can be appliable for any type of models... but it could have some performance problem for large sized model,
so then, we could apply NEW range interface which can restrict range of model data, so in example cases,
range {2, 4} then it only do filter or sort within range 2 to the 4.

for examples,

Orignal ModelSort Proxy Model{2,4}Filter Proxy Model (string "hy", {2,4})

The result of sort on a range is weird, but I can definitively see it working with filter or remote API like facebook and friends do. I am wondering where to put that API. Should it be an interface or should it be part of the default API of Model ?

Additional thinking regarding sorting and filter, as we want them to be an interface that any model can implement efficiently, we need a way to expose an API for filter/sort that would allow for example a SQL query to be build from it if possible. This kind of rules out a simple function callback and push for something more complex. Do anyone have any idea here ? Or example in other toolkit ?

What I can think of is of two idea :

  • Simple string to parse comparison rules
  • Complex object where you define property to read and comparison function being a type of object, basically building the Intermediate Representation that the string parsing above would do. From this object, you can define a walker code that would be able to interpret the representation to actually make a decision. This step could likely be optimized in many case to not require to walk real Eo object for each step of filter/sort.
SanghyeonLee added a comment.EditedDec 26 2018, 3:10 AM

@cedric in case of mega-data model, we might need to restrict data, and in unlimited-data case, it definitely necessary.
I don't think it may need to be an exposed API for every model, why not Proxy Model itself?

I agreed about two cases,
so I think it would be better to support simple string comparison by default, and for complex cases, promise/future with comparison function would be supported.

So far, I haven't really wanted to go through with a specific ProxyModel class, as it didn't seem necessary. Maybe it is an idea, but I think that if it is not part of the base Model API, then View that want to take advantage of that API, would want to check if the Model that was set provide that feature. Which means it should be an interface (I really think that for example a SQL model would implement that natively). Are you ok with that plan?

SanghyeonLee added a comment.EditedDec 27 2018, 9:37 PM

Yes this is not an urgent feature and can wait next release. just the discussion for which way is proper is the purpose for now.
the way I think about this is quite similar as QT sort/filter model does,
but we have more enough time to discuss about this.

Actually I really don't know how we can support this feature without making another sorted/filtered model from original model with keeping original data.

until we finish all urgent features of MVVM,
it will just remain as wishlist.

zmike added projects: efl: mvvm, Restricted Project.Jan 9 2019, 12:23 PM
zmike moved this task from Backlog to Felipe on the efl: mvvm board.