defaults passed as attributes should be bindable

[jrencz]

Some of the defaults can be dynamic, like a placeholder.
Not, once values not mentioned in tagsInput scope, they are treated as plain text.
There should be a way to make config dynamic, bindable.

[mbenford]

Hi Jarek.

I'm not sure I've understood what you mean. :(

Would you mind explaining it in more detail to me? I'll appreciate it.

[jrencz]

Let's say I'd like to pass a placeholder as an expression.
Now it's not possible.
We could develop some kind of initial checking and if value passed is valid expression then evaluate it. Or make it a scope variable

[mbenford]

Oh, I get it now. Thanks for clarifying it.

You can pass an expression to all options - placeholder included - as long as you wrap it up with {{ ... }}. Take a look at this Plunker script.

There's a caveat, though. Any expression is evaluated only once, when the directive is loaded. That's by design, since I believe directive's options aren't supposed to change after they are initialized. That may change in future versions if it turns out to be a bad design choice.

[jrencz]

Exactly - that's what I noticed.
In my project I need to get placeholder translated and for translations we use http://l20n.org/ which translates strings in realtime.
On regular basis we use https://github.com/EE/ng-l20n to manage translations keys in templates instead of in controllers. To use it I'd have to be able to set custom properties on actual <input>. Since there's no way to transfer properties from <tags-input> to <input> for now I patched ngTagsInput for my own usage: added attribute to <input> itself.

Wrapping up: both bindable options and attribute transferring (selective, I guess - which I hope to find some time and try to implement) would solve my problem.

[mbenford]

Ok, I understand now why you need to dynamically change the input placeholder. :)

You're not the first one trying to do that. I have added support for expressions in options precisely because another user had reported he needed to translate the placeholder text in runtime. But unlike you, he was using a custom filter to accomplish that, so a simple expression did the trick (placeholder="{{ value | translate }}").

Your idea of "attribute transferring" is kind of interesting, though. I'll think more about it.

[jrencz]

translate as a filter does not apply here since l20n does not translate strings. It does translate nodes.

Event better design choice would be to make ngTagsInput an attribute directive and keep original input - then you won't have to struggle rebinding events (not my case here, but I had this problem somewhere else).
But it's not a point of this feature request.

[mbenford]

From the very beginning ngTagsInput was intended to be used as a new HTML element. I wouldn't consider changing it into an attribute for the input tag unless that becomes a critical requirement. But who knows what the future holds? :)

If you run into more troubles, please let me know.

[jrencz]

I just wanted to make sure that during current project development if (when) I'd send some pull requests extending ngTagsInput functionality those pull requests will follow your main idea as much as possible (or at least won't break it). Otherwise I'll focus on developing features I need on my fork and then we'll try to find some common part of it some time later.