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 a get a single "updated" event, with the payload being the list of properties that changed value, pretty much like everywhere else, example: org.freedesktop.DBus.Properties.PropertiesChanged (STRING interface_name, DICT<STRING,VARIANT> changed_properties, ARRAY<STRING> invalidated_properties); > Also as pointed before, we are talking about only connecting > promise/future per information you are displaying in the current view. > There isn't going to be thousand of them and as long as they don't > block the UI, they won't matter. What matters is how easy we can write > a data model in any language. even that I think will be easier if we can do in a single "updated" event. -- 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
