Page MenuHomePhabricator

[MVVM] Support disabled composite model
Open, Incoming QueuePublic


To support user experience in MVVM widgets,
disable composite model is necessary.

as we discussed,
this class could be the sub-class of boolean composite model.

I think when we finish selection, this should be trivial. The merge that cedric did, did change model's interface and it broke quite a few model implementations. So, we are working on that as well.

sure I agreed. that is why I assign this task more lower priority than selections.

cedric added a subscriber: cedric.Nov 16 2018, 11:08 AM

Is this an enable/disable model ? If so, it can be implemented trivially by inheriting from the Boolean model. The main question being what kind of API do you want on top of it. Do we want a top level function that allow for example to define the state of an item to disable/enable without going through fetching the child object and setting its property ? Any other idea of what such a Model should provide ?

I think this task could be just moved our View Model Helper task. as you mentioned selection as a helper of ViewModel, enable disable is just one kind of pre-defined viewmodel property with some helpers.
for examples if widget is disabled, whole sub item need to be disabled. when the widget turns enabled, all sub item need to be enabled. and also when all sub item is disabled, widget could be disabled..
the helper API could be support this kind of simple works in my thought.

I don't think it is the duty of the model to do the propagation rules, but the items code should. So my idea would be that when the item fetch the property linked to enable/disable, it will call itself enable/disable on itself. This will cascade into enabling/disabling all of it child object following the widget logic, not something the model would provide itself. But maybe I am missing something about the logic of enable/disable.

well enable/disable is only the boolean data,
and principle is quite simple as all we know,

one is disabled, one is non-activated,
one is enabled, one is activated.

parent is disabled, children are disabled.
parent is enabled, children are .... ?

not sure about enable case, but if some children is disabled manually, it should not effected by parent's enablility.

I agreed the duty of propagation is only the role of item and widget.
view and item need to take care about propagation,
but still the boolean data of this enable/disable status need to be store somewhere...
we might not expose any helper class for this,
and only have one boleanComposite model for data only.

I might be wrong on this, but we already have this in our widget infrastructure. If you set a parent to disable, it does propagate that onto all the children automatically, no? If so, there isn't much of a need to actually deal with any propagation, we can just use a simple BooleanCompositeModel to provide the property.

We could btw add an helper on the Boolean Model to iterate on the true and on the false only Model. Would that be any useful for users?

Well I think about this as some package with selection for widget status.
we can just using boolean model and I fairly think that is enough for data storing..
but the way of providing API like disable set / get will be on item and widget unlikely selection will have helper in model.
that is one worry that I have about it.

There is no item with MVVM, they are Child Model. Item widget themself are only temporarily available (depending on the viewable area). That is why I think we need a way to do disable/enable things in an easy way. Could be on the View or on the Parent Model, not sure where. As for the API, logically, it should be index based (Otherwise you already have the Model and can directly say disable on it with property_set.

zmike moved this task from Backlog to Felipe on the efl: mvvm board.Jan 9 2019, 12:26 PM
SanghyeonLee added a comment.EditedJul 19 2019, 2:19 AM

@cedric @felipealmeida @bu5hm4n
as my understand, our efl_view_model or efl_ui_state_model need to take control some ui-related boolean states in the model data.
select/unselect (by interally adding select_model)

is it on the plan?

This is why we do have the Efl.BooleanModel and Efl.SelectModel.

SanghyeonLee added a comment.EditedAug 1 2019, 12:11 AM

I know that part,
but who will be managing the data? view itself? or viewmodel should?
we have statesmodel in the elementary,
I'm not sure we have plan to use them or not.
if it is unnecessary could we just remove it?

As I am working on Efl.Ui.CollectionView at the moment, I do absolutely plan to use this for handling all data. CollectionView shall not have any internal state related to any Item. It does completely break the design if we start to have random data not in the model as we can then not rely on MVVM infrastructure to use them.