On Mon, Apr 24, 2017 at 12:17 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Mon, 10 Apr 2017 23:46:43 -0300 Gustavo Sverzut Barbieri
> <barbi...@gmail.com> said:
[...]
>> Clear example with edc is to do chained animations, a series of
>> "after" must be chained, but if you need to cancel that you can't call
>> it a 'chain', you need to cancel all the program{} blocks... Also the
>> rel1/rel2 are very close to our internals, don't get into must
>> people's head that expect what the new "anchor" patchset is adding.
>>
>>
>> [...]
>> > 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.
>
> child objects in a tree that you haven't instantiated yet of source you don't
> get these cb's on... but parent objects could tell you if a child changed etc.
yes, that's my view as well, much simpler and people need a single
"updated" (or "changed") callback.
as for the model itself, I started to experiment with Facebook's
GraphQL, looks quite nice...
http://graphql.org/ (salesman bullshit)
https://facebook.github.io/relay/docs/thinking-in-graphql.html (good reasoning)
https://facebook.github.io/relay/docs/thinking-in-relay.html (how
their JS implementation works)
They have it easily linked with their UI framework (React) thus if you
use React + Relay you get automatic updates for all views given a
model property change, even if it was detected in an indirect query
(ie: you have a view with list of stories, another with the story
details... when the story details is updated, such as "like count",
then the list is automatically updated as well).
with caching and paging in the platform, given you conform to some
extra protocol (some properties/interfaces)... also great way they
handle "opportunistic updates"... and their "GraphQL" language to
describe queries, with fragments and all... is very Edc/Eo-like
syntax, they use that to generate JS, we could use that to generate C.
--
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
