Good to know. While doing this, I also see that I have a bug in the Dart version of PolymerExpressions such that it's returning the internal Scope object for node.templateInstance.model, so I have to write node.templateInstance.model.model. I need to fix that, but I feel like once you get into templateInstance you're digging a little too much into the internals of template binding to be generally accessible to non-experts.
Thanks, Justin On Thu, May 8, 2014 at 12:00 PM, Steve Orvell <[email protected]> wrote: > 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/CAEKsHmCwrvch7B_BEwKwdiehunDtgN4eB568po98vDNpbtDA%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
