Did anything ever happen here?
I'm trying to work up an example of a list with selection, and it'd be most
natural if I could either use a function expression as the binding, similar
to what Rafael was talking about in 2).
My template is something like:
<template repeat="{{ item in items }}">
<div class="item" on-click="{{ selectItem }}">{{ item }}</div>
</template>
The pain is in trying to figure which data object is being referenced,
since selectItem receives DOM objects, not my model objects. Looking at
core-list, I see I can get the model from the templateInstance, but that's
not so obvious. What I really want to do is:
<div class="item" on-click="{{ selectItem(item) }}">{{ item }}</div>
or even:
<div class="item" on-click="{{ item.select() }}">{{ item }}</div>
Cheers,
Justin
On Fri, Oct 18, 2013 at 4:24 PM, Scott Miles <[email protected]> wrote:
> Ok, I think I see what you mean: you would like to be able to delegate to
> a method on the sub-object in the iteration.
>
> I think we may be able to have our cake and eat it too here. Give us a few
> days to work on it.
>
> Scott
>
>
>
>
> On Fri, Oct 18, 2013 at 3:48 PM, Scott Miles <[email protected]> wrote:
>
>> On Fri, Oct 18, 2013 at 3:35 PM, Pete Blois <[email protected]> wrote:
>>
>>> Sorry, the view-model duality of the host always trips me up. Is there a
>>> better term than model for what the contents of a <template repeat> is
>>> bound to?
>>>
>>
>> No, IMO that's definitely a model in the standard sense.
>>
>> For the host node itself, I believe a close pattern is
>> Model-View-Presenter. Most properly then the host contains the
>> presenter-model, but we usually cheat and call it a view-model, or simply
>> model.
>>
>> The presenter-model is used to drive the UI and can be completely
>> distinct from your business-model (or overlapping or the same). And yes,
>> the `element` is it's own model, presenter, and view. This is the
>> packaging-by-functionality aspect of Polymer.
>>
>>
>>>
>>> With a deeply nested/bound UI such as:
>>> <template bind='{{somePath}}'>
>>> ...
>>> <template repeat='{{deeperStill}}'>
>>> ...
>>> <div on-click='{{goOffline}}'></div>
>>>
>>> The relation between the <div> and what the div is bound to is tight,
>>> but their relation to the host is somewhat loose, so it seems like the
>>> polymer-element code often just turns into some boilerplate 'fetch the
>>> model and call a method on it' which may as well be a static method.
>>>
>>>
>> Inside a template repeat you are potentially dealing with a sub-model,
>> depending on syntax, but it's by design that elements declared in a
>> polymer-element are under the purview of the host node.
>>
>> We probably need to see a problem case with more context.
>>
>> Scott
>>
>>
>>
>>> P.S. I still have difficulty reasoning about model-view separation when
>>> the model is a view.
>>>
>>> On Friday, October 18, 2013 3:01:08 PM UTC-7, Scott Miles wrote:
>>>
>>>> >> I'd still like to see binding to methods on the model, but
>>>> understand moving with caution.
>>>>
>>>> By design, when looking at a polymer-element, the host `element` is the
>>>> model and the methods are are on the `element`, so the `on-` syntax is
>>>> already "binding to methods on the model."
>>>>
>>>> I think I'm misunderstanding your point here.
>>>>
>>>>
>>>> On Fri, Oct 18, 2013 at 2:43 PM, Pete Blois <[email protected]> wrote:
>>>>
>>>>> Great to hear!
>>>>> I'd still like to see binding to methods on the model, but understand
>>>>> moving with caution.
>>>>>
>>>>>
>>>>> On Friday, October 18, 2013 1:32:15 PM UTC-7, Steve Orvell wrote:
>>>>>
>>>>>> Yeah, we're exploring doing all of polymer's event handlers via
>>>>>> binding for the reasons noted.
>>>>>>
>>>>>> My first stab is similar to the gist in that it overrides
>>>>>> Element.prototype.bind. I'm planning to move to the approach recommended
>>>>>> by
>>>>>> @jmesserly above, using expressions.
>>>>>>
>>>>>> We cannot do Rafael's #1 because we want to handle:
>>>>>>
>>>>>> <div on-click="{{clickHandler}}">
>>>>>>
>>>>>> and this is not a custom element.
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 18, 2013 at 1:19 PM, Rafael Weinstein
>>>>>> <[email protected]>wrote:
>>>>>>
>>>>>>> I believe Steve is already working on this. I imagine he will chime
>>>>>>> in soon. We discussed it yesterday.
>>>>>>>
>>>>>>> There are two (progressively fancier) versions of this:
>>>>>>>
>>>>>>> 1) <div on-click="{{ handleClick }">
>>>>>>>
>>>>>>> This would provide the benefits already mentioned. The
>>>>>>> implementation is likely inside the polymer base class whose bind()
>>>>>>> method
>>>>>>> will treat any on-* binding as a request to add an event listener to the
>>>>>>> provided function.
>>>>>>>
>>>>>>> 2) <div on-click="{{ addItem(currentItem) }}">, e.g. allow the
>>>>>>> function be an expression
>>>>>>>
>>>>>>> This would additionally require polymer-expressions to treat
>>>>>>> expressions inside on-* bindings specially. Notably, it will not
>>>>>>> register
>>>>>>> observers on anything in the expression, but will return an object whose
>>>>>>> value property is a wrapper function which closes over the model and
>>>>>>> evaluates the expression when it is invoked.
>>>>>>>
>>>>>>> I'm not a security expert, but I think we need to take care in
>>>>>>> designing both of these to avoid risk of creating XSS attack surface.
>>>>>>> One
>>>>>>> approach may be to only white list model functions are methods of
>>>>>>> polymer
>>>>>>> elements.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Oct 18, 2013 at 1:05 PM, John Messerly
>>>>>>> <[email protected]>wrote:
>>>>>>>
>>>>>>>> This is pretty neat. Am I understanding right: the idea is to move
>>>>>>>> the Polymer event bindings in Polymer Expressions? That way, they are
>>>>>>>> hooked up automatically when a <template> expands, without needing to
>>>>>>>> listen for events on the shadow root. So all of the bugs around
>>>>>>>> non-bubbling events go away. And it doesn't take much code either from
>>>>>>>> looking at the gist.
>>>>>>>>
>>>>>>>> Maybe the next step is try and land a pull request into Polymer
>>>>>>>> Expressions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Oct 12, 2013 at 11:58 AM, <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Something I've found useful in the past is to be able to bind
>>>>>>>>> functions from the model to UI events. I threw together a quick
>>>>>>>>> prototype
>>>>>>>>> of this, wondering if others think it's useful as well.
>>>>>>>>>
>>>>>>>>> Some hacked out prototype code is at- https://gist.github.com/pe
>>>>>>>>> teblois/6953310
>>>>>>>>>
>>>>>>>>> And it just allows doing something like:
>>>>>>>>> <template repeat='{{items}}'>
>>>>>>>>> <div *on-click='{{delete}}'*>
>>>>>>>>> </div>
>>>>>>>>> </template>
>>>>>>>>>
>>>>>>>>> function Item() {
>>>>>>>>> this.delete = this.delete.bind(this);
>>>>>>>>> }
>>>>>>>>> Item.prototype.delete = function() {
>>>>>>>>> // delete me!
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> It also allows event handlers to work on non-bubbling events (such
>>>>>>>>> as media events, which I'm not sure currently work in Polymer)-
>>>>>>>>> <template repeat='{{items}}'>
>>>>>>>>> <div class='{{watched: watched}}'>{{title}}
>>>>>>>>> <video src='{{url}}'
>>>>>>>>> *on-play='{{markAsWatched}}'*controls></video>
>>>>>>>>> </div>
>>>>>>>>> </template>
>>>>>>>>>
>>>>>>>>> Things which could be improved:
>>>>>>>>>
>>>>>>>>> - Better or automatic scoping of the function, so it doesn't
>>>>>>>>> need to be bound in the constructor.
>>>>>>>>> - Ability to specify function parameters. Though this doesn't
>>>>>>>>> really feel like a step back from the current events.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>>>>>>>>> ---
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "Polymer" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to [email protected].
>>>>>>>>>
>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Polymer" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Polymer" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
> Follow Polymer on Google+: plus.google.com/107187849809354688692
> ---
> You received this message because you are subscribed to the Google Groups
> "Polymer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups
"Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/polymer-dev/CAEKsHmBbysuM5OE4o9vJdFjcteKqUdr6MZQm4%3D8kkBzcbc0JoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
