Thank you for the thoughtful answer Dominic. S
On Mon, Feb 10, 2014 at 4:13 AM, Dominic Cooney <[email protected]> wrote: > In hindsight, this would be a great question for Stack Overflow. > > Dominic > > > On Fri, Feb 7, 2014 at 5:12 PM, Dominic Cooney <[email protected]>wrote: > >> On Thu, Feb 6, 2014 at 8:37 PM, Sébastien Cevey <[email protected] >> > wrote: >> >>> On 6 February 2014 05:59, Dominic Cooney <[email protected]> wrote: >>> >>> I was about to post to this ML to ask a very similar question, so pardon >>> me for hijacking this thread: >>> >>> >>>> Shadow DOM isn't a lock-box, there's also projection with <content>. It >>>> might be an interesting exercise to say "what should my markup look like?" >>>> and then try to work from there. >>>> >>> >>> I've just encountered a similar dilemma to Justin while building a >>> monitoring dashboard using Polymer. >>> >>> Please let me know if any of what I'm trying to do is an anti-pattern or >>> if there is a better alternative. >>> >>> The idea is to reuse custom elements through composition and a shared >>> interface: >>> >>> I've got a <my-chart> custom element that renders the data found in the >>> <table> it contains as a visual chart: >>> >>> <my-chart render="bar"> >>> <table>...</table> >>> </my-chart> >>> >> >> Yeah, it's interesting, isn't it? When there are elements like tables we >> kind of get into a grey area. I think your touchstone should be: >> >> How do I want people to be able to use my element? >> >> If I want people to be able to whack a my-chart around a table and render >> it, then yes, you should make that work. There's nothing that says this is >> the ONLY way my-chart can source its data, though... >> >> >>> Now I'd like to be able to feed data to <my-chart> from various sources, >>> as per the <polymer-ajax> example Dominic mentioned, through composition: >>> >>> <my-chart render="bar"> >>> <aws-cloudwatch metric="latency"></aws-cloudwatch> >>> </my-chart> >>> >>> <my-chart render="bar"> >>> <other-monitoring present="throughput"></other-monitoring> >>> </my-chart> >>> >>> >>> The problem here is that by default, the <aws-cloudwatch> and >>> <other-monitoring> elements will load data and populate a <table> _in their >>> Shadow DOM_. >>> >>> There seem to be two obvious solutions (not sure how technically doable >>> they are, I haven't tried yet): >>> >>> 1. Make <my-chart> look at the Shadow DOM of its children, rather than >>> their DOM. >>> 2. Make <aws-cloudwatch> and <other-monitoring> somehow populate their >>> DOM, rather than their Shadow DOM. >>> >>> Answering the "what should my markup look like?", it feels like 2. is >>> most reasonable (we want the tabular data in the DOM for clients to see, >>> right?). Is it right, or feasible? It doesn't feel like <content> would >>> help, though I might be mistaken. >>> >>> Alternatively, is this a misuse of Web Components? >>> >>> >>> I'd love to hear what you guys think and what are the suggested patterns >>> to do this, as it feels like composition of Web Components could be hugely >>> valuable! >>> >> >> I would definitely be using databinding and not DOM for this kind of >> composition. Assume you're in the middle of my-app, something like: >> >> <polymer-element name="my-app" attributes="data"> >> ... >> .. nonvisual stuff, push data into the model .. >> <aws-cloudwatch metric="latency" >> sink="{{data.latency}}"></aws-cloudwatch> >> >> .. visual stuff, pull data out of the model .. >> <my-chart render="bar" source="{{data.latency}}"></my-chart> >> >> It should not feel icky to have aws-cloudwatch not be a child of >> my-chart. That relationship might be convenient at first, but what if you >> want to have a chart AND a label that has 90 %-ile latency? Then you're >> going to want to have two visual widgets slurping off the same data and >> having the data source be a child of one element but not the other would be >> weird. >> >> It's also fine to have a complex data model in a given element. What's >> not OK is if some irrelevant detail of the my-app's data model bleeds into >> aws-cloudwatch or my-chart. >> >> It's neat if my-chart can also read from tables, and you could make it >> do that if source is missing or whatever. But I wouldn't make that the >> primary way to push data into it. >> >> If you end up slurping data from tables a lot, you might like to make a >> component which does that--wraps a table and brings its data into the >> databound world. >> >> >>> Thanks, >>> >>> -- >>> Sébastien Cevey >>> Software Developer >>> >>> Please consider the environment before printing this email. >>> ------------------------------------------------------------------ >>> Visit theguardian.com >>> >>> On your mobile, download the Guardian iPhone app theguardian.com/iphone and >>> our iPad edition theguardian.com/iPad >>> Save up to 57% by subscribing to the Guardian and Observer - choose the >>> papers you want and get full digital access. >>> Visit subscribe.theguardian.com >>> >>> This e-mail and all attachments are confidential and may also >>> be privileged. If you are not the named recipient, please notify >>> the sender and delete the e-mail and all attachments immediately. >>> Do not disclose the contents to another person. You may not use >>> the information for any purpose, or store, or copy, it in any way. >>> >>> Guardian News & Media Limited is not liable for any computer >>> viruses or other material transmitted with or as part of this >>> e-mail. You should employ virus checking software. >>> >>> Guardian News & Media Limited >>> >>> A member of Guardian Media Group plc >>> Registered Office >>> PO Box 68164 >>> Kings Place >>> 90 York Way >>> London >>> N1P 2AP >>> >>> Registered in England Number 908396 >>> >>> -------------------------------------------------------------------------- >>> >>> >>> >> >> >> -- >> Email SLA <http://goto.google.com/dc-email-sla> • >> Google+<https://plus.sandbox.google.com/111762620242974506845/posts> >> > > > > -- > <http://goto.google.com/dc-email-sla> > > 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/CAHnmYQ94UwQJdGdGXS09JJcZeSX3qX%3D6cX676uJJes%3Dq_be8eA%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/CAHbmOLayWMs6%3Dx1KTuKoy4-R4Kg9zRqO7WLsgtSQrEL0pSgOWw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
