>> Are the demo and index.html files expected to be a solid convention too?
It's not concrete yet, but the current concept is to suggest this structure as convention, yes. >> 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? The notion is that by including an `index.html` file, we have a standard convention that you can point your browser at a component folder, and get information about that component. The actual `index.html` we included in most of our elements today is a little weird, but let's not get stuck on that, the notion is as above. =P >> file that includes documentation and demos Yes, so we are trying to have our cake and eat it too. As I mentioned, we are putting some metadata/documentation directly in the `whatever-element.html` file, but factoring the documentation display infrastructure and demos to other files. >> The extra content could then be striped by tools like vulcanizer. Of course, that might not be any better than separate files. Yes, we cannot escape vulcanizer, but as much as possible we want to make it sort of an advanced thing. Scott On Sat, Feb 22, 2014 at 1:28 PM, Justin Fagnani <[email protected]>wrote: > 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/CAHbmOLaaj%3D7N4bsPjY2ccfP51t_H-%2BRpb-1Z-yAs%3DoHuBtaAPw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
