mirror of
https://github.com/flutter/flutter.git
synced 2026-02-20 02:29:02 +08:00
dddf8f294f
Instead of mojo.Shell and mojo.Application being clients of each other they are now separate interfaces. An implementation of mojo.Application receives a handle to the shell in its Initialize call, as described in this doc: https://docs.google.com/document/d/1xjt_TPjTu0elix8fNdBgWmnjJdJAtqSr1XDS_C-Ct8E/edit?usp=sharing An analogous change is made to the content handler definition. In C++, this is handled by the mojo::ApplicationImpl class which stores shell handle in its implementation of Initialize. Thus the only change for most C++ applications is the meaning of the handle in MojoMain is different, although mains that use the ApplicationRunners do the same thing with it. Connecting to other apps is largely the same although instead of grabbing the ApplicationImpl's client() to talk to the shell code must now use the ApplicationImpl::shell() getter. In JavaScript, the initialization sequence is a bit different although this is hidden mostly in the Application class which calls initialize() on its subclass with the same set of parameters. Connecting to another application looks different, especially for sky code using the shell proxy handle exposed via internals. Hans has some ideas about how to make this a bit nicer. Python apps similarly need to change their startup sequence a bit. I didn't find a common library to take care of this dance, although it's possible I just missed it. Other languages probably a bit of reworking - I fixed everything here that is covered by mojob.py test but some might be missing. This patch also uses typed handles (i.e. InterfacePtr<> or InterfaceRequest<> or their type aliases) wherever possible instead of ScopedMessagePipeHandle for clarity. R=davemoore@chromium.org Review URL: https://codereview.chromium.org/868463008
SkyElement
SkyElement is the framework for creating...yup...Sky Elements. It take heavy inspriation from Polymer and isn't very fully featured...yet
Declaring an element
<import src="../path/to/sky-element.sky" as="SkyElement" />
<template>
<my-other-element>Hello, {{ place }}</my-other-element>
</template>
<script>
// SkyElement takes a single object as it's only parameter
SkyElement({
name: 'my-element', // required. The element's tag-name
attached: function() {
this.place = 'World';
}, // optional
detached: function() {}, // optional
attributeChanged: function(attrName, newValue, oldValue) {} // optional
});
</script>
Note that an element's declared ShadowDOM is the previous <template>
element to the <script> element which defines the element.
Databinding
SkyElement's databinding support is derived from Polymer's. At the moment, there are some key differences:
There is not yet support for
- Declarative event handlers
- Inline expressions
- Self-observation (e.g.
fooChanged()gets invoked whenthis.foois changed) - Computed properties (e.g. the computed block)
- Conditional attributes (e.g.
<my-foo checked?="{{ val }}")
Also, because there are so few built-in elements in Sky, the default behavior of HTMLElement with bindings is to assign to the property. e.g.
<my-foo bar="{{ bas }}">
Will not setAttribute on the my-foo, instead it will assign to the bar
property of my-foo. There are two exceptions to this: class & style --
those stillsetAttribute.