New polymer release 0.12.0

[Siggi Cherem]

We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).

Polymer 0.12.0: here is a highlight of the changes since 0.11.0+5, check out the change log for more details: 

• Better support for two-way data-binding with Javascript polymer elements. This should make it much easier to use core and paper elements in your apps (example).
  
  
• Change in @published: There is a variation for how to declare @published properties. Instead of:

@published String foo;

we suggest you write:

@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);

The old style will continue to work, but the new style has a more predictable timing. In particular, say you use 'foo' in a binding, someone updates that binding, and later you read 'foo'. The old style has no guarantees about what you'll read out of 'foo'. If notifications have been propagated through the system, you'll see the latest value, but if not, you may see the old value. The new style guarantees that you'll see the new value in the binding regardless of the state of the notifications. This also matches how things work in polymer.js elements.

• @ComputedProperty: A new annotation has been introduced that lets you define a property in terms of other observable properties. For example you can write:

@ComputedProperty('a + b')

String get aPlusB => readValue(#aPlusB);

You can find more details in the dart docs for ComputedProperty

• PropertyPath: the syntax of property path changed. This is only relevant if you use you are not using polymer expressions, but use template-binding directly with it's default syntax. (see changelog for observe 0.11.0)
  
  
• Many bug fixes, especially around handling 'packages/' URLs, URLs with bindings, sanitizing file names, CSS shim of link-rels, and CSP support.

Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)

Cheers,

The polymer.dart team

[Günter Zöchbauer]

Thanks for the great work and for the info!

On Thursday, July 31, 2014 2:11:34 AM UTC+2, 'Siggi Cherem' via Dart Announcements wrote:

We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).

• Change in @published: There is a variation for how to declare @published properties. Instead of:

@published String foo;

we suggest you write:

@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);

Are the values of such properties reflected to the attribute and is @PublishedProperty(reflect: true) obsolete then or how does this relate to reflected properties?

 

[Kevin Moore]

Does the new syntax for @published also apply to @observable?

[Hans - Jürgen Alps]

Please also update the dart polymer homepage under https:// www.dartlang.org/polymer-dart/ . There is still the old syntax described.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_pK9j9uhRVTasMvxJ_-4mCLobTPPQHwhd1dNvD0tfHG1Q%40mail.gmail.com.

[曹忠]

1. @PublishedProperty(reflect: true) in  new syntax?

2. @observable similar behavior of @published in  new syntax?

在 2014年7月31日星期四UTC+8上午8时11分34秒，'Siggi Cherem' via Dart Announcements写道：

--
For more news and information, visit http://news.dartlang.org/
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

[Günter Zöchbauer]

@PublishedProperty(reflect: true) was introduced here https://groups.google.com/a/dartlang.org/forum/#!search/PublishedProperty(reflect$3A$20true)/web/rzJ9oVUZHTU/pnXQg3hodmMJ

I don't understand what you mean by 2.

[Vyacheslav Egorov]

> Change in @published ... we suggest you write:

To be honest I find it strange that we are moving from boilerplate (@published was already annoying to write) to even *more* boilerplate.

Seriously: foo is mentioned 4 times in the code, and the semantics is duplicated (set -> writeValue, get -> readValue) this is a very bad sign. 

Can we get a better picture of why this is needed? Is something missing in the language or libraries, why can't transformers do something like this for us, etc.

 

// Vyacheslav Egorov

--

[jolleekin]

PropertyPath's new syntax still doesn't support map indexers.

https://code.google.com/p/dart/issues/detail?id=20294

[Siggi Cherem]

@publishedProperty(reflect: true) is still needed if you want to make it reflected as an attribute. Both annotations work the same way in terms of timing, so you can do:

@PublishedProperty(reflect: true)

String get foo => readValue(#foo);

set foo(String value) => writeValue(#foo, value);

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.

[Siggi Cherem]

Only to @published. @observable continues to work as it did before. I'll be replying in more detail shortly when answering the later questions below.

--

For more news and information, visit http://news.dartlang.org/
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.

[Siggi Cherem]

On Wed, Jul 30, 2014 at 10:27 PM, Hans - Jürgen Alps <hansjuer...@googlemail.com> wrote:

Please also update the dart polymer homepage under https:// www.dartlang.org/polymer-dart/ . There is still the old syntax described.

Thanks for the reminder. We have this bug opened to work on it: https://code.google.com/p/dart/issues/detail?id=20245.

Note that the old syntax still works. The timing is the same that you had until today, so if you have a program that worked with 0.11.0+5, most likely it will continue to work afterwards.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CALz8j4dOcLsVwmBxR51hOeb_Og%2BU%3DD2o-cYG-w2Mk7j1HehD6g%40mail.gmail.com.

[Seth Ladd]

On Thu, Jul 31, 2014 at 10:15 AM, 'Siggi Cherem' via Dart Web Development <w...@dartlang.org> wrote:

On Wed, Jul 30, 2014 at 9:18 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Thanks for the great work and for the info!

On Thursday, July 31, 2014 2:11:34 AM UTC+2, 'Siggi Cherem' via Dart Announcements wrote:

We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).

• 
  
Change in @published: There is a variation for how to declare @published properties. Instead of:

@published String foo;

we suggest you write:

@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);

Are the values of such properties reflected to the attribute and is @PublishedProperty(reflect: true) obsolete then or how does this relate to reflected properties?

@publishedProperty(reflect: true) is still needed if you want to make it reflected as an attribute.

The intent isn't very clear in this annotation. Any more thoughts on calling this @attribute ? That's a lot more clear, at least to me :)  And then if it matters (for performance?)  @attribute(two-way: false)  (where two-way is the default)

"reflect" is an overloaded term, especially with mirrors.

 

Both annotations work the same way in terms of timing, so you can do:

@PublishedProperty(reflect: true)

String get foo => readValue(#foo);

set foo(String value) => writeValue(#foo, value);

 

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.

[Siggi Cherem]

On Wed, Jul 30, 2014 at 11:10 PM, 曹忠 <joo....@gmail.com> wrote:

1. @PublishedProperty(reflect: true) in  new syntax?

You can use this similar to @published. For example, you can do:

@PublishedProperty(reflect: true)

String get foo => readValue(#foo);

set foo(String value) => writeValue(#foo, value);

 

however, if you have no issues with the current timing of your property, you can feel free to leave it as it was.

2. @observable similar behavior of @published in  new syntax?

@observable stays as it was before.

 

--

You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/c994e238-f3a1-478a-802f-33f7f4a4e6d6%40dartlang.org.

[George Moschovitis]

Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)

Any chance you will also convert/wrap Googlewebcomponents (http://googlewebcomponents.github.io/) ?

-g.

[Grant]

On Thursday, July 31, 2014 2:05:53 PM UTC+2, Vyacheslav Egorov wrote:

To be honest I find it strange that we are moving from boilerplate (@published was already annoying to write) to even *more* boilerplate  

+1000 

[Siggi Cherem]

On Thu, Jul 31, 2014 at 5:05 AM, 'Vyacheslav Egorov' via Dart Web Development <w...@dartlang.org> wrote:

> Change in @published ... we suggest you write:

To be honest I find it strange that we are moving from boilerplate (@published was already annoying to write) to even *more* boilerplate.

Seriously: foo is mentioned 4 times in the code, and the semantics is duplicated (set -> writeValue, get -> readValue) this is a very bad sign. 

Can we get a better picture of why this is needed? Is something missing in the language or libraries, why can't transformers do something like this for us, etc.

I totally hear you - I agree that this is a lot of boilerplate and we've been actively thinking of ideas of what we can do to make it better. There are more questions than answers at this moment, so I'm hoping maybe some ideas can come up out of this discussion.

The background

polymer js implementation and ours were slightly inconsistent in how we dealt with published properties. The timing difference I mentioned in the first announcement is the visible effect to someone using the framework. The differences are very subtle, but you can read in detail what they are in dartbug.com/18343 comment #13.

In terms of implementation, the difference is that in Javascript they rewrite the prototype to change a field into a property, and we can't do that in Dart without a transformation.

This situation brought up a few questions:

Do we care about the timing differences? 

Yes.

It might matter for interoperability between JS elements and Dart elements. And it may be important if you want to rely on certain consistency between what you have in a binding and what you read from public properties of custom elements. Many of us have been building apps without running into this, but it is a race condition, so it might surprise you when you hit a bug related to this.

Are we willing to always require a transformation step?

Not yet.

Back in the days of web_ui we were always running a compiler. With pub-serve, a transformer runs when launching code in Dartium, so it is possible to adjust @published properties during this transformation.

On the other hand, we don't require using pub-serve today. Polymer has the advantage that it can run in Dartium without any code transformations. I think some of our users need this for situations where it is not easy to use pub-serve. For example, if you have a server for your application that includes some JSON API, and you want to use it while developing the code in Dartium. With same-origin restrictions, you end up having to serve the Dart code from that server. It's possible to set up a proxy from your server to pub-serve, but it's not trivial.

IMHO, we shouldn't require a transformation step until we have an easy and reliable mechanism to support these scenarios. There are many tricks we can use to get there, but they require a considerable amount of work or changes in either the language or the infrastructure. For example, some ideas are:

• Build libraries people can add to their servers to automatically proxy requests (see issue 18039).
• Create a chrome extension that runs the transformation before the page loads in Dartium. We did this for web_ui, but it was hard for users to keep it up to date and deal with multiple versions of the package.
• Run the compiler as a script that launches the app as a new isolate. This requires changes in Dartium which are not expected for a while.
• Ask for changes in the language that would let us do the transformation while the app is loaded. Or changes that would allow us to override properties dynamically.

Are we willing to have different semantics before & after transforming the code?

Maybe?

We could say that by default @published is transformed, but when running in Dartium it may have race conditions. This hybrid approach might lead to surprising results when something works/doesn't work in one mode but works in the other. We could use the boilerplate code as a fallback for those who run into issues, but the problem is that the annotation lives in code that you might not be able to modify (code in a shared library).

At this moment it felt that exposing the boilerplate code was the most gradual change we could make and continue to have a consistent semantics in both the non-transformed and the transformed code. We are still thinking and brainstorming ideas to make this better, so any suggestion is always welcomed :-).

I should note that the old style of @publish is still supported, so feel free continue using it if you prefer to wait while we figure out the best way to move forward.

Looking forward to your comments,

Siggi

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAPD5VRuTDpnAfaDG8rriE2Cn8QWcBBkunrF%2B07SM%2BO8mfLhZSw%40mail.gmail.com.

[Seth Ladd]

- announce,eng

On Thu, Jul 31, 2014 at 10:25 AM, George Moschovitis <george.mo...@gmail.com> wrote:

Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)

Any chance you will also convert/wrap Googlewebcomponents (http://googlewebcomponents.github.io/) ?

Hi George,

I'm under the impression that they should "just work". Did you run into a bug when you tried them?

 

-g.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/27b6b7ad-4906-41c0-b914-d2425ef4c720%40dartlang.org.

[Siggi Cherem]

On Thu, Jul 31, 2014 at 10:20 AM, 'Seth Ladd' via Dart Announcements <anno...@dartlang.org> wrote:

On Thu, Jul 31, 2014 at 10:15 AM, 'Siggi Cherem' via Dart Web Development <w...@dartlang.org> wrote:

On Wed, Jul 30, 2014 at 9:18 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:

Thanks for the great work and for the info!

On Thursday, July 31, 2014 2:11:34 AM UTC+2, 'Siggi Cherem' via Dart Announcements wrote:

We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).

• 
  
Change in @published: There is a variation for how to declare @published properties. Instead of:

@published String foo;

we suggest you write:

@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);

Are the values of such properties reflected to the attribute and is @PublishedProperty(reflect: true) obsolete then or how does this relate to reflected properties?

@publishedProperty(reflect: true) is still needed if you want to make it reflected as an attribute.

The intent isn't very clear in this annotation. Any more thoughts on calling this @attribute ? That's a lot more clear, at least to me :)  And then if it matters (for performance?)  @attribute(two-way: false)  (where two-way is the default)

I should clarify here: published properties are always two-way. What's changing is whether the property value is also visible as an attribute if you look at the element and read the attribute either in code or through css selectors. For example:

If you have:

  <x-foo bar="{{e}}"></x-foo>

You get a 2-way binding between e and XFoo.bar, even when 'reflect' is false. However, if you do:

var x = querySelector('x-foo');

x.bar = "hi";

...

print(x.attributes["bar"]);

this prints 'hi' if only if 'reflect' is true.

"reflect" is an overloaded term, especially with mirrors.

We've been trying to keep the declarations and defaults consistent between polymer.dart and polymer.js. In polymer.js they use the term `published` when declaring published properties in code, and by default the value is not reflected back in the corresponding HTML attribute (details here).  My understanding is that this was for performance reasons - it's too expensive to reflect all properties back to attributes, when only a few are used. So they wanted to make this opt-in.

It's unfortunate that the term 'reflect' conflicts with Dart's notion of mirrors and reflection, but we want to make sure that the concepts in polymer.js are easy to translate to a polymer.dart app. One option here is to make it more verbose, for example `reflectBack` or `reflectInAttribute`.

Thoughts?

Siggi

 

 

Both annotations work the same way in terms of timing, so you can do:

@PublishedProperty(reflect: true)

String get foo => readValue(#foo);

set foo(String value) => writeValue(#foo, value);

 

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.

--
For more news and information, visit http://news.dartlang.org/
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.

[Siggi Cherem]

On Thu, Jul 31, 2014 at 1:09 PM, 'Seth Ladd' via Dart Web Development <w...@dartlang.org> wrote:

- announce,eng

On Thu, Jul 31, 2014 at 10:25 AM, George Moschovitis <george.mo...@gmail.com> wrote:

Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)

Any chance you will also convert/wrap Googlewebcomponents (http://googlewebcomponents.github.io/) ?

Hi George,

I'm under the impression that they should "just work". Did you run into a bug when you tried them?

The elements should "just work" without any modification to their code, but until we get a better bower integration with pub, there are changes you need to do after doing a `bower install` to get everything actually working.

The main issue is that we need to load any shared code from a single place. So common imports, like 'polymer.html', needs to be adjusted. This includes common components that are packaged for Dart (for example if they use a core or paper element, you'll need some extra fixes.)

That being said, it should be simple to make this process automatic. We do so in the core- and paper- packages with a script here:

https://github.com/dart-lang/paper-elements/blob/master/tool/update.dart

That script rewrites the bower polymer.html to import polymer.dart's copy of polymer.html. The code we have is the same, but this way polymer is always loaded from the same place and therefore only loaded once:

https://github.com/dart-lang/paper-elements/blob/master/lib/src/polymer/polymer.html

The script also rewrites elements for which we have 2 copies, and pick the one in our packages. For instance 'core-input' is defined in core_elements, so we override the code to import it from there:

https://github.com/dart-lang/paper-elements/blob/master/lib/src/core-input/core-input.html

The tool uses a configuration file to figure out what to generate, for example this is where we specify that:

https://github.com/dart-lang/paper-elements/blob/master/paper_elements_config.yaml#L30

The sources for this script are available for you to use. They live today in the core_elements package, but we'd like to move it out into it's own repo soon.

Cheers,

Siggi

 

-g.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/27b6b7ad-4906-41c0-b914-d2425ef4c720%40dartlang.org.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CACr%3D8_Of8UYuibAXW5ZzDQtyGy8npeR6Cb1qyQbsuSEebxk%2BHg%40mail.gmail.com.

[Seth Ladd]

+1 to using the word "attribute" somehow.

Thanks for the explanation!

 

Thoughts?

Siggi

 

 

Both annotations work the same way in terms of timing, so you can do:

@PublishedProperty(reflect: true)

String get foo => readValue(#foo);

set foo(String value) => writeValue(#foo, value);

 

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.

--
For more news and information, visit http://news.dartlang.org/
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Vyacheslav Egorov]

I see, thanks for the background. 

Indeed it seems we are in a very unfortunate situation here where language is simply to restrictive and lack expressive power to achieve something that JavaScript can achieve easily. 

I think we should put the following restrictions on ourself here:

1) We should never tolerate boilerplate;

2) We should match JavaScript behavior;

3) We should have fast edit-refresh cycle (which means avoid transformers when running in the pure Dart mode).

I think under this requirements there is no way to solve the problem that we are having here without some additional language feature, at least if we also want to retain the same syntax and declarative nature of published attributes.

One potential improvement I can think about would be to allow property decoration (as opposed to simple annotation).

class X {

  @@published T f;

}

could be interpreted as:

class X {

  T get f => const published(#f).get(this);

  set (T value) { const published(#f).set(this, value); }

}

// Vyacheslav Egorov

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_pvLKor-ZTMdUZfr1ZdMNN1DJi9ay-oU%2B_dCaonObp%3Dpw%40mail.gmail.com.

[Seth Ladd]

On Fri, Aug 1, 2014 at 7:38 AM, 'Vyacheslav Egorov' via Dart Web Development <w...@dartlang.org> wrote:

I see, thanks for the background. 

Indeed it seems we are in a very unfortunate situation here where language is simply to restrictive and lack expressive power to achieve something that JavaScript can achieve easily. 

I think we should put the following restrictions on ourself here:

1) We should never tolerate boilerplate;

2) We should match JavaScript behavior;

3) We should have fast edit-refresh cycle (which means avoid transformers when running in the pure Dart mode).

Nicely put.

 

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAPD5VRsYV6w2Up1sUccmV4KHdhHoERmFADfAvKqNSO8EJP-Y9g%40mail.gmail.com.

[Teddy Clarke]

I agree with @Vyacheslav Egorov.

Though I see the reason for the new setter/getter, it should not come at the expense of grossly excessive boilerplate code. The increase number of keystrokes from @published to the new form is astonishing. Even in the official polymer-dart tutorial at https://www.dartlang.org/polymer-dart/#custom-attributes the recommendation was not used - @published was used instead. I think there is some more work to do with the suggested replacement for @published.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CACr%3D8_OfXKY66b8kQKALQjoLkvEMuZX-Yp1x3Dfuc0cPqfDP%2BQ%40mail.gmail.com.

[George Moschovitis]

I'm under the impression that they should "just work". Did you run into a bug when you tried them?

Maybe we have a  different interpretation of 'just work'. I would like to do just a 'pub get' and be ready to add html imports to my page.

In other words, I am looking for a pub package similar to core_elements and paper_elements.

[Seth Ladd]

Gotcha, thanks. I think the plan is to integrate Bower with Pub somehow, or let them play nicely together: https://code.google.com/p/dart/issues/detail?id=19354

unfortunately, it's not scalable to put every web component into pub. We'll need a way to work with Bower.

Glad to see the interest in the google-components!

 

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/1bf49d2a-f10c-4279-8e57-ab868c709112%40dartlang.org.

[Sergey Shevchenko]

We handle both Bower and Pub packages in Chrome Dev Editor, so if we could have a formalized, step-by-step, guaranteed-to-work description of what needs to be done, we could do it.

Also, several thoughts on @PublishedProperty(reflect: true) and the new boilerplate with readValue/writeValue:

* First of all, if you're writing a library of reusable elements, you can't possibly know how they will be used on the other end. That means that the whole thing is a must: otherwise, your end users are bound to run into and give you a headache with bizarre timing issues (we've have more that a fair share of those with our own widgets in CDE).

* Second, among the possible solutions that Siggi has suggested under 'Are we willing to always require a transformation step?', quite a few might not work with Chrome apps (e.g. a server proxying requests). Just something to keep in mind.

* Third, at least speaking of @PublishedProperty(reflect: true) vs. @attribute debate, I've added the following in a common source included by all the widgets in CDE:

const attribute = const PublishedProperty(reflect: true);

...and use it as:

@attribute foo;

Question is, is it possible to expand that to auto-generate the entire readValue/writeValue boilerplate? Does Dart's annotations allow that?

[Hans - Jürgen Alps]

I would also appreciate if there is a step by step description how to integrate GoogleWebComponents into a dart project. Actually I'm working on a project to automatically generate testreports and I"m using Google Charts for that purpose. As there is no dart package available for Google Charts I"m using JavaScript, but I'm missing many darts features already.

@Sergey you wrote that you are using both Bower and pub packages in CDE. But actually polymer projects don"t work with CDE. See https://github.com/dart-lang/chromedeveditor/issues/2872 . This bug is still open.

If there is a way how to integrate Bower based components into Dart then this should be handled the same way in Dart Editor and CDE. Projects that work in Dart Editor should also work in CDE without changes and vice versa.

I would also appreciate if Sergey"s suggestion concerning published attributes could be implemented in a future version of polymer.

[Siggi Cherem]

On Fri, Aug 8, 2014 at 10:51 PM, Sergey Shevchenko <serg...@google.com> wrote:

We handle both Bower and Pub packages in Chrome Dev Editor, so if we could have a formalized, step-by-step, guaranteed-to-work description of what needs to be done, we could do it.

Also, several thoughts on @PublishedProperty(reflect: true) and the new boilerplate with readValue/writeValue:

* First of all, if you're writing a library of reusable elements, you can't possibly know how they will be used on the other end. That means that the whole thing is a must: otherwise, your end users are bound to run into and give you a headache with bizarre timing issues (we've have more that a fair share of those with our own widgets in CDE).

* Second, among the possible solutions that Siggi has suggested under 'Are we willing to always require a transformation step?', quite a few might not work with Chrome apps (e.g. a server proxying requests). Just something to keep in mind.

* Third, at least speaking of @PublishedProperty(reflect: true) vs. @attribute debate, I've added the following in a common source included by all the widgets in CDE:

const attribute = const PublishedProperty(reflect: true);

...and use it as:

@attribute foo;

Question is, is it possible to expand that to auto-generate the entire readValue/writeValue boilerplate? Does Dart's annotations allow that?

Unfortunately annotations can't do that. However, to follow up on the feedback and discussions we had here, last week we've started some discussions with the language designers to see if we can pursue some new language feature in this direction. 

 

On Friday, August 1, 2014 11:46:37 AM UTC-7, sethladd wrote:

On Fri, Aug 1, 2014 at 11:27 AM, George Moschovitis <george.mo...@gmail.com> wrote:

I'm under the impression that they should "just work". Did you run into a bug when you tried them?

Maybe we have a  different interpretation of 'just work'. I would like to do just a 'pub get' and be ready to add html imports to my page.

In other words, I am looking for a pub package similar to core_elements and paper_elements.

Gotcha, thanks. I think the plan is to integrate Bower with Pub somehow, or let them play nicely together: https://code.google.com/p/dart/issues/detail?id=19354

unfortunately, it's not scalable to put every web component into pub. We'll need a way to work with Bower.

Glad to see the interest in the google-components!

 

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.

Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/1bf49d2a-f10c-4279-8e57-ab868c709112%40dartlang.org.

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/5a517c24-ca74-4462-9556-cec59712547f%40dartlang.org.

[tomasz.kubacki]

On Wednesday, August 13, 2014 4:13:36 AM UTC+2, sigmund wrote:

Question is, is it possible to expand that to auto-generate the entire readValue/writeValue boilerplate? Does Dart's annotations allow that?

Unfortunately annotations can't do that. However, to follow up on the feedback and discussions we had here, last week we've started some discussions with the language designers to see if we can pursue some new language feature in this direction. 

 

Any news on @PublishedProperty boilerplate ?

Did you manage to find a path Dart/Polymer team will follow to resolve the issue?

[Jonas Kello]

"Are we willing to always require a transformation step?" "Not yet."

I agree with this, and would say, "Please, please, not ever".

I also agree with @Vyacheslav but understand that it is very hard to reconcile all of his three items. So if we are forced to choose, I would say that item 3 (no transformers) is the most important and should override item 1 (no boilerplate) if necessary.

Like everyone else, I do not like boilerplate. However I dislike “black magic” even more than I dislike boilerplate. Transformers create code that I cannot even see, and if I cannot put a breakpoint on it, then to me it is “black magic” :-). With frameworks that apply a lot of this magic you are basically in a bad place if somethings goes wrong. Also they tend to only be useful for showing of in very simple hello-world or todo items examples. But once you have a large scale complex application you will be willing to trade anything for the ability to see what is actually going on when you debug a really complex scenario involving multiple change notifications triggering each other, and reading properties with timing issues etc.

The explicit syntax for reading and writing the property is actually pretty much how it looks in C# with INotifyPropertyChange and ppl have been doing that for many years without too much complaint. I think Dart should try to do better, but if it is not possible it is nice to know that having explicit notifications are not that bad as has been proven in practice.

Also, in C# there was originally a problem because the notification used strings that had to match the property name which was not refactor friendly. Some smart ppl came up with a way to have a lambda for the property name which would change with property rename refactoring. In Dart we have the #Symbol syntax which is really nice because we don’t have to rely on magic strings and the #Symbol name changes when we refactor rename it’s target. However, I think the analyzer is not checking if the #Symbol actually exists? This makes it easy to make spelling mistakes which are not easy to discover. If there is an issue for this let me know and I will star it.

/Jonas

[Siggi Cherem]

Hi Tomasz,

Thanks for following up. Sorry I don't have a more definite update - we are still in the process of resolving this. We have had many discussions about language changes to support this and made great progress though. I'll make sure to keep you posted here when I have more details.

Cheers,

Siggi

--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/aac160f2-120b-484a-8654-76f91f3830ff%40dartlang.org.

[John Messerly]

On Wed, Dec 31, 2014 at 2:09 AM, Jonas Kello <jonas...@gmail.com> wrote:

"Are we willing to always require a transformation step?" "Not yet."

I agree with this, and would say, "Please, please, not ever".

For what it's worth, I completely agree with you Jonas.

Transformers of Dart code are intended to be optional and just for convenience.

For example, here's manual `@observable` annotation from the tests:

https://github.com/dart-lang/observe/blob/9d4ef338a86e53a6d907bd3f62fe5144be7b6628/test/list_path_observer_test.dart#L68

It's also mentioned in the observe docs: http://www.dartdocs.org/documentation/observe/0.12.2/index.html#observe/observe

That's one thing I like about the new way of writing "published" properties ... they just have normal getters/setters, and the readValue/writeValue pattern isn't too bad. It's even cleaner than the "observe" expansion, IMO.

To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/eeeb395b-88de-474c-a1ce-9694fb8f4dc9%40dartlang.org.

[曹忠]

I dislike the readValue/writeValue. Indeed weird: set foo(var value) {writeValue(#foo, value); window.console.log("notthing output!"))}

在 2015年1月8日星期四UTC+8上午7时11分06秒，John Messerly写道：