Simply declarative events

Simply declarative events.

This patch simplifies declarative events such that there are only two notions:

1) A controller: This is found by walking up the DOM until a shadow host or lightDom controller (i.e. polymer-body) is encountered. 

2) A method name: When event is handled by the controller, it attempts to find a member function with a matching name and invoke it.

Notably, this removes the behavior (that apparently no one was actually using), where by a mustache could contain a *path* (e.g. foo.bar) and the function foo.bar is looked up, not from the model, from the controller and invoked with the controller as the receiver value.


R=sorvell
BUG=

Committed: https://github.com/Polymer/polymer-dev/commit/34d96dc

[rafaelw, 2014-04-25 22:17:15]

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

[arv, 2014-04-28 16:19:46]

Now I am forced to put my handlers at the top of the model. What is the
motivation of this change?

[sjmiles, 2014-04-28 16:47:38]

On 2014/04/28 16:19:46, arv wrote:
> Now I am forced to put my handlers at the top of the model. What is the
> motivation of this change?

Yes, this seems like a regression of features. I know (1) Raf and Steve
discussed it and (2) the fancier version has non-trivial difficulties, but I'd
prefer not to just punt the whole idea if we don't have to.

[rafaelw1, 2014-04-28 16:59:25]

The root problem is that this feature had super wonky semantics. The way it
was, it always treated the "controller" as the receiver value, and it got
that by walking up the tree, even though the function was retrieved by
following the model-path.

The way it is now is nice and simple. Putting handlers deeper in the model
probably only makes sense if the receiver is the object to which the
handler is attached. However, this is will fail for the simple cases, like
{{ foo }} because the model is a scope object, not the element, which means
that rules for finding a receiver are:

If the path is a single property, walk up the DOM, otherwise use the object
holding the handler.



On Mon, Apr 28, 2014 at 9:47 AM, <sjmiles@google.com> wrote:

> On 2014/04/28 16:19:46, arv wrote:
>
>> Now I am forced to put my handlers at the top of the model. What is
>>
> the
>
>> motivation of this change?
>>
>
> Yes, this seems like a regression of features. I know (1) Raf and Steve
> discussed it and (2) the fancier version has non-trivial difficulties,
> but I'd prefer not to just punt the whole idea if we don't have to.
>
> https://codereview.appspot.com/97750045/
>

[sjmiles, 2014-04-28 17:45:01]

>> The way it is now

Sorry, I'm confused which behavior you describe is the new way vs the old
way.

Fwiw, it's useful to be able to bind events directly to handlers on other
elements, e.g.

  on-input="{{$.keys.input}}"

This is the main use case I'd like to support.

Scott


On Mon, Apr 28, 2014 at 9:59 AM, Rafael Weinstein <rafaelw@google.com>wrote:

> The root problem is that this feature had super wonky semantics. The way
> it was, it always treated the "controller" as the receiver value, and it
> got that by walking up the tree, even though the function was retrieved by
> following the model-path.
>
> The way it is now is nice and simple. Putting handlers deeper in the model
> probably only makes sense if the receiver is the object to which the
> handler is attached. However, this is will fail for the simple cases, like
> {{ foo }} because the model is a scope object, not the element, which means
> that rules for finding a receiver are:
>
> If the path is a single property, walk up the DOM, otherwise use the
> object holding the handler.
>
>
>
> On Mon, Apr 28, 2014 at 9:47 AM, <sjmiles@google.com> wrote:
>
>> On 2014/04/28 16:19:46, arv wrote:
>>
>>> Now I am forced to put my handlers at the top of the model. What is
>>>
>> the
>>
>>> motivation of this change?
>>>
>>
>> Yes, this seems like a regression of features. I know (1) Raf and Steve
>> discussed it and (2) the fancier version has non-trivial difficulties,
>> but I'd prefer not to just punt the whole idea if we don't have to.
>>
>> https://codereview.appspot.com/97750045/
>>
>
>

[rafaelw1, 2014-04-28 17:49:17]

On Mon, Apr 28, 2014 at 10:45 AM, Scott Miles <sjmiles@google.com> wrote:

> >> The way it is now
>
> Sorry, I'm confused which behavior you describe is the new way vs the old
> way.
>

What's presently checked in.


>
> Fwiw, it's useful to be able to bind events directly to handlers on other
> elements, e.g.
>
>   on-input="{{$.keys.input}}"
>
> This is the main use case I'd like to support.
>
>
Does this mean: "when the input event fires, I want to invoke the 'input'
method on $.keys"?


> Scott
>
>
>
> On Mon, Apr 28, 2014 at 9:59 AM, Rafael Weinstein <rafaelw@google.com>wrote:
>
>> The root problem is that this feature had super wonky semantics. The way
>> it was, it always treated the "controller" as the receiver value, and it
>> got that by walking up the tree, even though the function was retrieved by
>> following the model-path.
>>
>> The way it is now is nice and simple. Putting handlers deeper in the
>> model probably only makes sense if the receiver is the object to which the
>> handler is attached. However, this is will fail for the simple cases, like
>> {{ foo }} because the model is a scope object, not the element, which means
>> that rules for finding a receiver are:
>>
>> If the path is a single property, walk up the DOM, otherwise use the
>> object holding the handler.
>>
>>
>>
>> On Mon, Apr 28, 2014 at 9:47 AM, <sjmiles@google.com> wrote:
>>
>>> On 2014/04/28 16:19:46, arv wrote:
>>>
>>>> Now I am forced to put my handlers at the top of the model. What is
>>>>
>>> the
>>>
>>>> motivation of this change?
>>>>
>>>
>>> Yes, this seems like a regression of features. I know (1) Raf and Steve
>>> discussed it and (2) the fancier version has non-trivial difficulties,
>>> but I'd prefer not to just punt the whole idea if we don't have to.
>>>
>>> https://codereview.appspot.com/97750045/
>>>
>>
>>
>

[sjmiles, 2014-04-28 17:54:39]

>> If the path is a single property, walk up the DOM, otherwise use the
object holding the handler.
>> What's presently checked in.

Are these the same thing?

>> Does this mean: "when the input event fires, I want to invoke the
'input' method on $.keys"?

Yes.


On Mon, Apr 28, 2014 at 10:49 AM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Mon, Apr 28, 2014 at 10:45 AM, Scott Miles <sjmiles@google.com> wrote:
>
>> >> The way it is now
>>
>> Sorry, I'm confused which behavior you describe is the new way vs the old
>> way.
>>
>
> What's presently checked in.
>
>
>>
>> Fwiw, it's useful to be able to bind events directly to handlers on other
>> elements, e.g.
>>
>>   on-input="{{$.keys.input}}"
>>
>> This is the main use case I'd like to support.
>>
>>
> Does this mean: "when the input event fires, I want to invoke the 'input'
> method on $.keys"?
>
>
>> Scott
>>
>>
>>
>> On Mon, Apr 28, 2014 at 9:59 AM, Rafael Weinstein <rafaelw@google.com>wrote:
>>
>>> The root problem is that this feature had super wonky semantics. The way
>>> it was, it always treated the "controller" as the receiver value, and it
>>> got that by walking up the tree, even though the function was retrieved by
>>> following the model-path.
>>>
>>> The way it is now is nice and simple. Putting handlers deeper in the
>>> model probably only makes sense if the receiver is the object to which the
>>> handler is attached. However, this is will fail for the simple cases, like
>>> {{ foo }} because the model is a scope object, not the element, which means
>>> that rules for finding a receiver are:
>>>
>>> If the path is a single property, walk up the DOM, otherwise use the
>>> object holding the handler.
>>>
>>>
>>>
>>> On Mon, Apr 28, 2014 at 9:47 AM, <sjmiles@google.com> wrote:
>>>
>>>> On 2014/04/28 16:19:46, arv wrote:
>>>>
>>>>> Now I am forced to put my handlers at the top of the model. What is
>>>>>
>>>> the
>>>>
>>>>> motivation of this change?
>>>>>
>>>>
>>>> Yes, this seems like a regression of features. I know (1) Raf and Steve
>>>> discussed it and (2) the fancier version has non-trivial difficulties,
>>>> but I'd prefer not to just punt the whole idea if we don't have to.
>>>>
>>>> https://codereview.appspot.com/97750045/
>>>>
>>>
>>>
>>
>

[rafaelw1, 2014-04-29 00:10:30]

On Mon, Apr 28, 2014 at 10:54 AM, Scott Miles <sjmiles@google.com> wrote:

> >> If the path is a single property, walk up the DOM, otherwise use the
> object holding the handler.
> >> What's presently checked in.
>
> Are these the same thing?
>
>
What's presently checked in always does this:

1) Expect the binding value to be a property on the controller
2) Walk up the DOM looking for the controller (will be shadowHost or
lightDomController)
3) Try to invoke method on the controller.


> >> Does this mean: "when the input event fires, I want to invoke the
> 'input' method on $.keys"?
>
> Yes.
>

We should talk about this in person. AFAICT, this really isn't about the
model, it's about DOM. You are always wanting to invoke a method of an
element. The fact that these things are reachable via the model is really
ancillary. I continue to claim that isn't a concern of databinding. That's
not to say that we shouldn't use the same syntax (which I think can be an
orthogonal issue), but I think it's helpful to think about the problem the
right way.

Put another way, this is the only case we have in "databinding" where the
value here isn't being handed into the node's bind() method.


>
>
> On Mon, Apr 28, 2014 at 10:49 AM, Rafael Weinstein <rafaelw@google.com>wrote:
>
>> On Mon, Apr 28, 2014 at 10:45 AM, Scott Miles <sjmiles@google.com> wrote:
>>
>>> >> The way it is now
>>>
>>> Sorry, I'm confused which behavior you describe is the new way vs the
>>> old way.
>>>
>>
>> What's presently checked in.
>>
>>
>>>
>>> Fwiw, it's useful to be able to bind events directly to handlers on
>>> other elements, e.g.
>>>
>>>   on-input="{{$.keys.input}}"
>>>
>>> This is the main use case I'd like to support.
>>>
>>>
>> Does this mean: "when the input event fires, I want to invoke the 'input'
>> method on $.keys"?
>>
>>
>>> Scott
>>>
>>>
>>>
>>> On Mon, Apr 28, 2014 at 9:59 AM, Rafael Weinstein
<rafaelw@google.com>wrote:
>>>
>>>> The root problem is that this feature had super wonky semantics. The
>>>> way it was, it always treated the "controller" as the receiver value, and
>>>> it got that by walking up the tree, even though the function was retrieved
>>>> by following the model-path.
>>>>
>>>> The way it is now is nice and simple. Putting handlers deeper in the
>>>> model probably only makes sense if the receiver is the object to which the
>>>> handler is attached. However, this is will fail for the simple cases, like
>>>> {{ foo }} because the model is a scope object, not the element, which
means
>>>> that rules for finding a receiver are:
>>>>
>>>> If the path is a single property, walk up the DOM, otherwise use the
>>>> object holding the handler.
>>>>
>>>>
>>>>
>>>> On Mon, Apr 28, 2014 at 9:47 AM, <sjmiles@google.com> wrote:
>>>>
>>>>> On 2014/04/28 16:19:46, arv wrote:
>>>>>
>>>>>> Now I am forced to put my handlers at the top of the model. What is
>>>>>>
>>>>> the
>>>>>
>>>>>> motivation of this change?
>>>>>>
>>>>>
>>>>> Yes, this seems like a regression of features. I know (1) Raf and Steve
>>>>> discussed it and (2) the fancier version has non-trivial difficulties,
>>>>> but I'd prefer not to just punt the whole idea if we don't have to.
>>>>>
>>>>> https://codereview.appspot.com/97750045/
>>>>>
>>>>
>>>>
>>>
>>
>