On Tue, 25 Apr 2017 11:15:00 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> 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():
yeah. i was thinking the event info could contain this in a list or array of
property names or something.
> 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
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
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
