Skip to content
This repository has been archived by the owner on Nov 19, 2018. It is now read-only.

Does not work for Extended <file-input> #51

Closed
marutypes opened this issue Mar 9, 2015 · 10 comments
Closed

Does not work for Extended <file-input> #51

marutypes opened this issue Mar 9, 2015 · 10 comments
Labels
Milestone

Comments

@marutypes
Copy link
Contributor

I was building an extension of which parses and displays a file preview for each valid file. This does not work in the current implementation of <ajax-form> since the maybeParseFileInput function checks the tag name explicitly. This also means that <ajax-form> does not work with any alternate web component implementations of a file input.

I'm working on a pull request to fix this.

@rnicholus
Copy link
Owner

As long as your element exposes an input element with a type attribute of "file", there should be no issue. Otherwise, I'm not sure how you would identify such an element.

@marutypes
Copy link
Contributor Author

  • If the input inherits from <file-input>, the input element is hidden inside the shadow dom and doesn't seem to get parsed.
  • Since the maybeParseFileInput function checks for the tag name it doesn't get parsed their either.
  • Since the maybeParseGenericCustomElement function only checks the value it also doesn't get parsed there...

Have tested this myself using an element which works in a native form.

@rnicholus
Copy link
Owner

Ajax-form checks for a file-input element, or any input element that has an attribute of type=file. Short of this, I'm not sure how you would identify such an element, short of some very specific convention.

What is your specific plan to address this?

@marutypes
Copy link
Contributor Author

Well, it is a 'very specific convention' itself to check specifically for file-input. I'd argue it's more general and makes more sense with Polymer's inheritance mechanisms to check if there is a .files attribute similar to how you check for a value attribute in the genericCustomElement parsing.

I say this because it defies user expectations to be disallowed from wrapping or extending due to an overly specific parsing implementation.

@rnicholus
Copy link
Owner

Yes, that particular convention is in place as I am also the developer of file-input. I suppose that convention could be removed and the custom element parser could be augmented to check for the files property.

@marutypes
Copy link
Contributor Author

Ok cool. That's what I was doing for the pull request. Glad you get my point :)

@rnicholus
Copy link
Owner

Yep, as long as an additional specific convention is not introduced, that should be fine. I'd suggest removing the file-input specific code while you're at it.

@rnicholus
Copy link
Owner

Also, curious what your element's code looks like. I've done quite a bit of work with the File API, scaling, previewing images, etc.

@marutypes
Copy link
Contributor Author

I'll be putting what I have so far up on webcomponents.io soon. Hadn't seen your link before, looks cool.

@rnicholus
Copy link
Owner

Released as part of 1.5.4.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants