Page MenuHomePhabricator

[MVVM] Create a ViewModel helper class
Closed, ResolvedPublic


In the MVVM pattern, having an easy to start from ViewModel where you can quickly just implement the computation logic for your object property is a must. This proxy model would be in charge of doing a few things :

  • Allow for easy writing of new custom property (think about where an item get the label value it needs, or the color attribute, ...)
  • Automatically forward properties change to the View
  • Link properties change from incoming models to custom property so that the View will automatically get notified when to refetch a property.

Any other behavior ?

cedric created this task.Nov 16 2018, 11:27 AM

Maybe we want ViewModel to handle UI configuration in imperative paradigm, or should it stay as Eina_Value's only?

I am not sure what you have in mind, could you share an example ? I am thinking that at this point, we let the developer implement property get in the binding language, so in an imperative form. But the propagation of changed event can be done in a declarative way. You just need to say, when this property change in any model I am proxying, this local property also will have a different result. That would be the way to automate that part. At the end, it is just an array to generate by fetching information from a small hash table.

we can support changed event by interface like, Efl.Ui.Observable

Efl.Ui.Observable still use Eina_Value and strings to carry over the value itself and expend the cost of model by enforcing one Eo object per property you are using which is going to be a serious problem I think.

The only small simplification is that you don't have to do monitor and dispatch in the event handler of a property change on the model. I think this is an optimization that should not really matter. You could, if you are manually listening on a property and updating your UI (Not using connect), just always refresh the View. The dispatch that check if the property has changed and only update the View in that case is after all just an optimization.

The second request is how to make things not work based on string and Eina_Value.

Basically at the C level, I think this is impossible. Even if we use C function, the code would have to use dladdr which take a string and has no type associated with the returned pointer. Same apply with if we had something generated, I don't see how the language would allow that.

In C#, there is a language integration and so it is possible to hide the dispatching logic and generate it. We could extend Eo to do all the generation and have a table that would be called by the property_get function and do the dispatching automatically for us. Sadly, I think we are out of time for this option, even if neat.

Also I am not sure what is the issue we are trying to address with this attempt to remove strings and Eina_Value from the API. In most case, the only place where you will have to work with string and Eina_Value is in the ViewModel property_get code itself. It very much depends on how the code is implemented in the binding. So I am not to sure, here of what the state of the code is in the C# binding for example. Still in any of this kind of language, you should have the conversion to the type you are looking for being done for you with maybe an error being thrown if the property you are getting from other model resulted in an error. In go, it would look like :

value, err := model.property_get("toto")

In most case I can see, value can then be used with any kind of operation as Eina_Value do provide conversion function so type doesn't matter there so much. Of course you would have strange result if you were expecting a number and received a string, so your addition result would become a concatenation, but that will be easy to see quickly. Also with proper test infrastructure, this kind of mistake can be detected pretty quickly.

Basically, I do not understand the problem we are trying to address by wanting property strongly typed.

I think we should probably leave for bindings to do the kind of magic that eases coding.

This comment was removed by woohyun.
cedric closed this task as Resolved.Wed, Jan 2, 1:40 PM