Intended use-cases for polymer-file?

[David James]

I just looked over this nice presentation:

http://html5-demos.appspot.com/static/polymer/index.html#24

I have some questions about slide 24 "Everything is an element, read files...using DOM".

Here is the code from the slide:

<polymer-file readas="dataurl"></polymer-file>

var pFile = document.querySelector('polymer-file');

pFile.addEventListener('polymer-result', function(e) {

  console.log(this.result);

});

pFile.blob = new Blob(['abc'], {type: 'text/plain'}); // Set the file to read

pFile.read();

This seems like madness; why use an *element* to read a file at all? Reading a file is fundamentally an action. Wrapping up an action in a structural element (intended for a UI) seems ill-conceived.

Am I missing something? Perhaps polymer-file is *only*intended to represent a file upload UI component?

[hal...@gmail.com]

You would use this instead of <input type='file'>. I haven't used this this component (or polymer / webcomponents in general) but it appears to be part of a component that wraps the File API.

-T-Bone

[Rob Dodson]

Hi David,

The polymer-file element is from the old deprecated set and I don't think we're actively using it anywhere. Having said that, we are using other similar elements like core-ajax and core-localstorage. One thing to keep in mind is that you use similar elements all the time: <script> and <style> both perform non-visual actions (handing scripts off to the JS engine or CSS parser).

The power of core-ajax and core-localstorage does not become immediately obvious until you factor in data binding. With data binding in play, these elements become very easy to use data providers that require little to no javascript to wire up. For example, here's an element that takes a search term and lists all the YouTube videos that match that term using databindings and core-ajax: http://jsbin.com/woteru/7/edit

Docs for core-ajax are here if you're interested: http://www.polymer-project.org/docs/elements/core-elements.html#core-ajax

The nice thing is you don't have to use any of these elements if it doesn't jive with how you'd like to build your app. In some cases they're a handy tool and in other instances you may prefer to do it all in script. It's entirely up to you :)

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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/2ec8f0ed-4515-4749-9578-5750dab21a28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Bidelman]

Hi David,

Watch this section from my Google I/O presentation and this article in the docs. It covers types of HTML elements, both visual and non-visual. Things start to make sense when you compare non-visual custom elements existing elements we today in the web platform. What we'll have tomorrow...? that will be defined by us web developers :)

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwAAAANpCT5U%2Be-0rrZRj1bHZfoGqFdJ3_xT7%2B8mhMMO8Q%40mail.gmail.com.

[Scott Miles]

Another less obvious benefit to wrapping behavior in elements is modularization. Similar to asking a module system to provide a behavior, you can create an element to provide that encapsulation.

I can write a function that will perform as task given a service moniker:

document.createElement(service).doTask(); 

With very slight sugaring, you could create a method like this:

service(<service-name>[, config]).doTask();

The fact that the `service` object has HTMLElement as a base can be ignored if you like, but we are already leveraging namespacing (element names are managed by the system) and we can also take advantage of it's ability to be inserted into a (DOM) tree, which provides a convenient structure for command and control.

On Mon, Sep 15, 2014 at 1:16 PM, 'Rob Dodson' via Polymer <polym...@googlegroups.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAJj5OwAAAANpCT5U%2Be-0rrZRj1bHZfoGqFdJ3_xT7%2B8mhMMO8Q%40mail.gmail.com.

[David James]

Thanks for the discussion. I can see the advantages of using elements for more than just UI controls, but I still have battle scars from Flex + ActionScript many years ago. :) I've seen various projects get carried away with tag-based programming.