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). 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. -- Cedric BAIL ------------------------------------------------------------------------------ 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
