On Apr 24, 2017 07:03, "Gustavo Sverzut Barbieri" <barbi...@gmail.com>
wrote:
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).
We have been looking with Felipe about using graphql for more than remote
call (still having support for a graphql data model would be useful). One
of our idea was to use it for type checking data model. When you write your
proxy model, you have to check the type of everything you access if you
want to be able to reuse that proxy with a different source. The idea would
be to have a proxy model that take a graphql and a data model to
automatically generate error when the type don't match your proxy model
expectation. This would simplify writing proxy data model a bit. Of course
error are automatically forwarded to the view and the view has a value to
display in case of error.
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.
I don't understand what you have in mind that could be generated from
graphql, could you explain what you have in mind ?
Cedric
------------------------------------------------------------------------------
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
