Update polymer to commit b7200854b2441a22ce89f6563963f36c50f5150d

Update polymer to commit b7200854b2441a22ce89f6563963f36c50f5150d

This brings over the changes to event dispatching.

R=blois@google.com

Committed: https://code.google.com/p/dart/source/detail?r=29303

[Siggi Cherem (dart-lang), 2013-10-25 21:05:25]

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
File pkg/polymer/test/event_handlers_test.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
pkg/polymer/test/event_handlers_test.dart:93: @reflectable Function
itemTapAction;
I'm not proud of this hack, but it works.

[blois, 2013-10-25 21:25:10]

changes lgtm

[Jennifer Messerly, 2013-10-25 22:00:41]

this is looking awesome :)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/decl...
File pkg/polymer/lib/src/declaration.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/decl...
pkg/polymer/lib/src/declaration.dart:315: value.replaceAll('{{',
'').replaceAll('}}', '').trim();
in JavaScript they're just replacing the first occurrence ("replace" instead of
"replaceAll"). Should we do that as well? Should the second replace start from
the end (JS does not do that but maybe a bug)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
File pkg/polymer/lib/src/instance.dart (left):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:615: subl.cancel();
ouch! nice catch

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:766: void _listenLocal(Polymer host, Event
event) {
yay! so much code gone :)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
File pkg/polymer/lib/src/instance.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:742: static invokeMethod(receiver, Symbol
methodName, List args) {
fyi -- this is an instance method in Polymer:

https://github.com/Polymer/polymer/blob/master/src/instance/properties.js#L96

consider making this private and re-exposing the instance method

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:1031: class
_PolymerExpressionsWithEventDelegate extends PolymerExpressions {
I wonder if we should make this functionality available to third party syntaxes?
I know a few people have implemented their own syntax thingies :)

e.g. extract your getBinding into a public method that takes the original
getBinding. Then implement this class via:

class _PolymerExpressionsWithEventDelegate extends PolymerExpressions {
  getBinding(model, path, name, node) {
    return Polymer.getBindingWithEvents(model, path, name, node,
super.getBinding);
  }
}

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:1062: if (ctrlr is! Polymer) return;
fyi -- _findController should not return something that isn't a Polymer mixin

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
File pkg/polymer/test/event_handlers_test.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
pkg/polymer/test/event_handlers_test.dart:93: @reflectable Function
itemTapAction;
On 2013/10/25 21:05:26, Siggi Cherem (dart-lang) wrote:
> I'm not proud of this hack, but it works.

hmmm. interesting I thought PolymerExpressions "Method" workaround should handle
this. but not sure what is going on :)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
File pkg/polymer/test/event_path_declarative_test.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
pkg/polymer/test/event_path_declarative_test.dart:16: override:
'polymer.test.event_path_declarative_test')
consider: using @reflectable instead. it's cleaner :)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
pkg/polymer/test/event_path_declarative_test.dart:91: // We shouldn't care about
registration order though. See dartbug.com/14459
hmmm. I think registration order does matter. Generally you want your
dependencies registered first. It is fine to rely on that.

I think we're only hitting this due to our lame single-<script> tag restrictions
:|

IMO, not using CustomTag for this case is totally fine.

[Siggi Cherem (dart-lang), 2013-10-26 00:02:34]

thanks!

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/decl...
File pkg/polymer/lib/src/declaration.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/decl...
pkg/polymer/lib/src/declaration.dart:315: value.replaceAll('{{',
'').replaceAll('}}', '').trim();
On 2013/10/25 22:00:41, John Messerly wrote:
> in JavaScript they're just replacing the first occurrence ("replace" instead
of
> "replaceAll"). Should we do that as well? Should the second replace start from
> the end (JS does not do that but maybe a bug)

Done.

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
File pkg/polymer/lib/src/instance.dart (left):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:615: subl.cancel();
On 2013/10/25 22:00:41, John Messerly wrote:
> ouch! nice catch

dart2js warning =)

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
File pkg/polymer/lib/src/instance.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:742: static invokeMethod(receiver, Symbol
methodName, List args) {
On 2013/10/25 22:00:41, John Messerly wrote:
> fyi -- this is an instance method in Polymer:
> 
> https://github.com/Polymer/polymer/blob/master/src/instance/properties.js#L96
> 
> consider making this private and re-exposing the instance method

Done.

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/lib/src/inst...
pkg/polymer/lib/src/instance.dart:1031: class
_PolymerExpressionsWithEventDelegate extends PolymerExpressions {
On 2013/10/25 22:00:41, John Messerly wrote:
> I wonder if we should make this functionality available to third party
syntaxes?
> I know a few people have implemented their own syntax thingies :)
> 
> e.g. extract your getBinding into a public method that takes the original
> getBinding. Then implement this class via:
> 
> class _PolymerExpressionsWithEventDelegate extends PolymerExpressions {
>   getBinding(model, path, name, node) {
>     return Polymer.getBindingWithEvents(model, path, name, node,
> super.getBinding);
>   }
> }

Good idea, done.

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
File pkg/polymer/test/event_handlers_test.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_h...
pkg/polymer/test/event_handlers_test.dart:93: @reflectable Function
itemTapAction;
On 2013/10/25 22:00:41, John Messerly wrote:
> On 2013/10/25 21:05:26, Siggi Cherem (dart-lang) wrote:
> > I'm not proud of this hack, but it works.
> 
> hmmm. interesting I thought PolymerExpressions "Method" workaround should
handle
> this. but not sure what is going on :)

me neither. I'll be submitting this shortly and look more into this afterwards.

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
File pkg/polymer/test/event_path_declarative_test.dart (right):

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
pkg/polymer/test/event_path_declarative_test.dart:16: override:
'polymer.test.event_path_declarative_test')
On 2013/10/25 22:00:41, John Messerly wrote:
> consider: using @reflectable instead. it's cleaner :)

good point. done.

https://codereview.chromium.org/44573005/diff/150001/pkg/polymer/test/event_p...
pkg/polymer/test/event_path_declarative_test.dart:91: // We shouldn't care about
registration order though. See dartbug.com/14459
On 2013/10/25 22:00:41, John Messerly wrote:
> hmmm. I think registration order does matter. Generally you want your
> dependencies registered first. It is fine to rely on that.
> 
> I think we're only hitting this due to our lame single-<script> tag
restrictions
> :|
> 
> IMO, not using CustomTag for this case is totally fine.

we talked about this offline - I'll keep the comment here because in this case
the order shouldn't matter. We are seeing 'ready' and 'created' being called
more times because of this.

[Siggi Cherem (dart-lang), 2013-10-26 00:42:32]

Committed patchset #1 manually as r29303 (presubmit successful).