Support adding add-ons

[zoechi]

I don't know if this is possible, but it would be nice if I could pass in custom add-ons to be handled by the paper-input-containers add-on support (like it's now with prefix and suffix).

[MeTaNoV]

Maybe you should not try to wrap a <paper-input> but instead, write your own input based on Polymer.PaperInputBehavior and <paper-input-container> where you will have maximum flexibility. This is the case for gold elements and I also adopted this strategy for my <gold-password-input>
Moreover, you might have some nasty side-effect if your are then using it in the scope of an <iron-form> (cf. <iron-input> Issue 64)

[zoechi]

@MeTaNoV I was thinking about this too.
I am curious if there are specific reasons why this is not supported like "nobody found the time to do it", "there are technical hurdles", "this is not what this element is intended to do", ...

[MeTaNoV]

@zoechi I think <paper-input> is to be considered as a semi-generic implementation based on more generic elements like mentioned above and as such, should be regarded as an example to build your own custom input.
@notwaldorf could probably answer this question better! :)

[chiefcll]

<paper-input> can still be generic and add tons of options / functionality by including <content select="[add-on]"></content>

I was able to completely style paper-input to how I wanted it but now not being able to add an add-on is my major hurdle. I'll submit a patch.

[notwaldorf]

Yeah @MeTaNoV is right. paper-input is supposed to be a generic, out of the box input. If you need to start adding custom add-ons, you should use paper-input-container. At the moment, I am hesitant to add this to paper-input since it's quite an expensive element already, and there's a bit of effort being made trying to slim it down --this would mean making it less of a "kitchen sink" element (which is reserved for paper-input-container), and more of a "it works for you out of the box, or it doesn't" kind of element.