On Mon, 24 Apr 2017 11:03:31 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> 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)
a quick read of graphql - i like it. it's simple. and it actually does the
caching like above.... (and only fetch what you need).
> 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
>
--
------------- 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
