On Tue, Apr 25, 2017 at 5:06 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Mon, 24 Apr 2017 14:27:55 -0300 Gustavo Sverzut Barbieri
> <barbi...@gmail.com> said:
>
>> On Mon, Apr 24, 2017 at 1:50 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
>> > On Sun, Apr 23, 2017 at 8:17 PM, Carsten Haitzler <ras...@rasterman.com>
>> > wrote:
>> >> On Mon, 10 Apr 2017 23:46:43 -0300 Gustavo Sverzut Barbieri
>> >> <barbi...@gmail.com> said:
>> >>> On Mon, Apr 10, 2017 at 7:12 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
>> >
>> > [...]
>> >
>> >>> > We have been iterating over a MVC design for more than a year now. I
>> >>> > think we are nearing a design that start to look good. The funny part
>> >>> > is when I was trying to find some presentation to explain people about
>> >>> > MVC and the difference with what we were doing, I stumble on Microsoft
>> >>> > MVVM design pattern which is pretty close to the design we have
>> >>> > selected. So we will rename the work we have done from ProxyModel to
>> >>> > ViewModel to use the same naming convention as everyone else.
>> >>> >
>> >>> > The main difference between MVC and MVVM is that it allow the
>> >>> > definition of a clean interface between View and Model. There isn't
>> >>> > really a ProxyModel or ViewModel interface, as they really are just a
>> >>> > Model that get data from another Model and interpret them into what
>> >>> > the View will actually display. This means you can easily reuse Model
>> >>> > and that you can test your Proxy/ViewModel without connecting it to an
>> >>> > actual View.
>> >>> >
>> >>> > And last very nice benefit, I think, is that you are defining a
>> >>> > "connection" for each parameter of your widget. So to connect a View
>> >>> > with a Model, you are only setting the model and indicating which
>> >>> > property to fetch on the model. No need to deal with callback in many
>> >>> > case ! For an example (which is broken at the moment) of the idea you
>> >>> > can look at layout_model_connect.c in efl elementary example.
>> >>> >
>> >>> > The most complex work will now be in writing this Proxy or View Model.
>> >>> > This is something we have to work on to make it easier.
>> >>>
>> >>> I've talked to you and felipe at IRC, I still think that the current
>> >>> Model is trying to address too much of "performance and async" at the
>> >>> level that it will suck for developers.
>> >>>
>> >>> to address the correct goal of "never block", what the current
>> >>> implementation does is make all property-get async, resulting in a
>> >>> promise... callback, etc. Whenever you need a simple:
>> >>>
>> >>> if (model.a + model.b < model.c) do_bla(model);
>> >>>
>> >>> then you're screwed... you need to store these elsewhere, wait on 3
>> >>> callbacks, then execute what you want. Okay, helpers to accumulate and
>> >>> wait on all futures... then dispatch an array of values will be there,
>> >>> but still.
>> >>>
>> >>> caching is also left to outside. But to cache properly you need to
>> >>> know your information, access pattern, load coast, evict cost... Okay,
>> >>> applications may know better which information they are going to use,
>> >>> but they can hint that to model if needed (we could add a way to
>> >>> declare "hot properties").
>> >>
>> >> i personally prefer the idea of caching. have the item object and list
>> >> which properties you want fetched, and some thread fetches in the
>> >> background. when it's done your promise or callback is triggered. once it
>> >> is you can be certain the properties are already fetched and live in
>> >> memory. it's not a promise per property to fetch. it's "get me all of this
>> >> in a blob" and should be simpler to deal with. this is where i dislike
>> >> promises for this. i prefer some "updated" callback... as below, it'd work
>> >> better with live updates. if an object changed at the source - the model
>> >> can be listening and it already knows what properties you want... and it
>> >> can auto re-fetch them and then call the "updated" callback. you only have
>> >> to register that cb on that object once to handle all cases.
>> >
>> > The all in one blob doesn't work well for multiple reason. First you
>> > are connecting a data model to each widget directly, so each widget
>> > needs now to know how to extract the value it needs from that blob
>> > (Solution range from using a hash and a string in an eina value, to
>> > something like eet or even give an eo object that inherit from
>> > efl_part). It also means that the code in the proxy model will get
>> > more complex than you envision as you need to fetch from the blob the
>> > property you want before doing your operation and packing them in the
>> > result blob. Using a blob increase the complexity of writing a data
>> > model and make life for binding quite more complex (Don't forget we
>> > want to be able to write data model in any language).
>>
>> I believe he said "one blob" as in "one go", for example you query and
>
> gustavo understood me. you'd have an item object and maybe something like:
>
> obj = efl_add(parent, MY_UI_ITEM_CLASS,
> efl_callback_add(efl_added, EFL_EVENT_CHANGED, on_changed,
> NULL),
> efl_model_property_request(efl_added, "label"),
> efl_model_property_request(efl_added, "width"),
> efl_model_property_request(efl_added, "height"));
> // actually trigger an update manually
> efl_model_update(obj);
>
> // and in on_changed:
>
> static void on_changed(void *data, Efl_Event *event)
> {
> Eina_Value *label = efl_model_property_get(event->object, "label");
> Eina_Value *width = efl_model_property_get(event->object, "width");
> Eina_Value *height = efl_model_property_get(event->object, "height");
> // XXX: do something with the values we got
> }
This could be even prettier in some cases where you could report the
properties that changed, so if you simply want to printf():
const char **what_changed = event->info;
for (;*what_changed; what_changed++)
{
Eina_Value val = efl_model_property_get(event->object, *what_changed);
char *str = eina_value_to_string(&val);
printf("changed %s: %s\n", *what_changed, str);
free(str);
eina_value_flush(val); // would make it a value, not pointer to
make it lean on memory
}
> of course if you use the MVVM stuff where you connect properties to somethnig
> else then you dont need the above property_gets as they are done for you.
>
> it's the model's job to go fetch async then store the property values in the
> object... and once ALL the requested properties have been fetched and stored
> in
> the ui item class (inherits from model item)... then you can get them
> guaranteed with no blocking as they are stored/cached.
yep
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
