No progress yet. The current way is what you noted and I agree it's absolutely not intuitive. We do want to support probably both sytaxes you proposed with the latter having higher priority.
On Thu, May 8, 2014 at 11:53 AM, 'Justin Fagnani' via Polymer < [email protected]> wrote: > 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<https://groups.google.com/d/msgid/polymer-dev/CAEKsHmBbysuM5OE4o9vJdFjcteKqUdr6MZQm4%3D8kkBzcbc0JoQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > 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/CA%2BrMWZhNzJtNrEsZfe2m4PiNHMXLqkUqpyt%3DNu2RMZbAvMEE0Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
