Has any thought been given to packaging metadata with the components in a standard way, ie. are the metadata files that Designer uses available and appropriate for other tools to use?
Also, the property-event-attribute association, this actually _is_ needed at runtime if a consumer needs to create a 2-way bindings, unless Node.bind() will always be public API. On Sat, Feb 22, 2014 at 1:19 PM, Scott Miles <[email protected]> wrote: > As I mentioned, our philosophy at the moment is that the code itself > should be as close as possible to optimized for run-time use. Additionally, > we prefer that the bower-able packages have as little non-runtime content > as possible. Both principles are aimed to reduce our general footprint. > > However, this is all on a spectrum. > > Current exceptions to the code rule include meta-data in comments, which > today we use for documentation and cataloging. We could conceivably expand > this metadata to accommodate tooling, it's all a matter of balance. > > Designer (nee Sandbox) uses separate metadata files to do it's thing. Our > experience is that IDE tools can take advantage of more metadata than we > are comfortable putting directly into the run-time file. > > Current exceptions to the package rule include legal claptrap (which we > want to reduce; at this level of granularity, reproducing each of those > files N times is poor ergonomics), the demo file, and the index.html file > (all of which I'm still stressing about =P). > Are the demo and index.html files expected to be a solid convention too? Excuse my ignorance, since I'm coming at the from the Dart side and don't have a lot of experience with the JS widgets. What is the index.html file? One idea I had seen a while ago was that the actual element definition could be in a file that includes documentation and demos - a very fat declaration, fluent-programing style. The extra content could then be striped by tools like vulcanizer. Of course, that might not be any better than separate files. Thanks, Justin > > Scott > > > > On Fri, Feb 21, 2014 at 6:12 PM, Justin Fagnani > <[email protected]>wrote: > >> Joining this thread a little late, but I'd like to come back to the >> original topic of declaring the public interface for a custom element. >> We've talking about this in person, but to recap: >> >> I think this is critical for good tooling for custom elements. Tools >> can't assume this fixed set of elements where they know all the events, >> properties and attributes of an element. This is obviously an issue for >> design-time tools, but runtime tools have problems too: a framework that >> wants to support way data binding needs to be able to understand the >> relationship of attributes, properties and events, so that it can properly >> use them to bind to a single "property". >> >> I'm not sure how the sandbox demo figures out what properties to make >> editable in the inspector, does it use the attributes attribute? If so, >> does it then use Node.bind with that attribute name, or does it just set >> the attribute? >> >> -Justin >> >> >> >> On Fri, Feb 14, 2014 at 11:41 PM, Scott Miles <[email protected]> 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]>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]. >>>> 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/CAHbmOLZrFs%3DA24hGyP9Ab8uHDeMqsSUU1%2BQB%3Dd7dpUzSC8TEKg%40mail.gmail.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/CAEKsHmCpP6Knw-ug1Om6HadarObXYkFGgJ11Fphd85zwKb2zHA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
