Good point. How about the following function that custom-events could have: - (as already proposed) in the element's definition, all fire() and asyncFire() calls would be checked to match an event in the custom-events; - at the instantiation point, all non-standard-DOM on-*event* attributes would also be checked against the custom-events.
I'm not sure what weight Polymer Dart has on general Polymer JS development, but I think it needs to be mentioned that in Polymer Dart, the attributes property's purpose has already shifted towards documenting/code validity checking: it is always required that a published property be defined in the element's Dart implementation; the developer can also add it to the element's attributes, but the only goals that serves are: - to better inform the user about the element's API; - to check that all properties listed in attributes have @published counterparts in the implementation - just listing a name there never auto-creates a property. On Friday, February 14, 2014 11:41:15 PM UTC-8, Scott Miles wrote: > > The reason we haven't done this is because it would be unique in our > system to have live DOM or JavaScript code whose only purpose is > documentation. I'm not saying it's off the table, but it would be crossing > a line. All other declarations (in particular `attributes`) have a runtime > function, any documentary service is incidental. > > > On Fri, Feb 14, 2014 at 8:40 PM, Sergey Shevchenko > <[email protected]<javascript:> > > wrote: > >> ...and as commented by Seth Ladd on the said Dart Web Development: >> >> <quote> >> >> I'd love this. >> >> I see four APIs for custom elements: >> >> * Custom attributes >> * Custom events >> * Children elements (yes, even adding a child element is a type of API) >> * The elements imperative API (aka pure Dart code) >> >> I hope we can demonstrate superior toolability for all surface areas of a >> custom element. >> >> </quote> >> >> On Friday, February 14, 2014 8:38:10 PM UTC-8, Sergey Shevchenko wrote: >> >>> Hi all, >>> >>> (reposting from Dart Web Development) >>> >>> With "attributes", we have some way to succinctly communicate to an >>> element's users what properties they can set at the instantiation point. >>> Why don't we have something similar for custom events that an element can >>> fire? Something like: >>> >>> <polymer-element name="my-element" attributes="height width" >>> custom-events="open activate"> >>> >>> ... >>> >>> <my-element height="100" width="200" on-open="onOpen" >>> on-activate="onActivate"></my-element> >>> >>> The way it is now, users are left to either rely on the documentation >>> (unreliable) or hunt all fire() and asyncFire() calls in the element's code. >>> >>> If "custom-events" were added, it would be nice to also check, for every >>> fire()/asyncFire() call, that the element actually declares the event being >>> fired. >>> >>> I bet all this would save a lot of debugging hours for a lot of people. >>> >>> --Sergey >>> >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/a6394d86-c4c1-4070-80e1-cca9840c776d%40googlegroups.com >> . >> >> 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/425cb313-98f8-4fa1-830a-42a752d6d445%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
