String.Format in value bindings

We’d like to support string formatting capabilities in value and resource bindings. We are considering how the syntax should like. We want to use .NET format strings so the formatting works the same way on both server side and client side.

The most preferred solution is to keep the .NET way, so the binding would look like this:

`{value: string.Format(“Test {0} {1:yyyy/M/d}”, Id, CreatedDate)}

However, we need to decide how the function should be named:

• string.Format - my personal favorite, everybody understands what it means, the problem is that it’s quite long and the users will expect that other .NET functions will work in the bindings too.
• _dotvvm.format - maybe it would be a good idea to introduce the _dotvvm alias which will contain this kind of functions. We have several controls which render their own functions (e.g. the RouteLink uses the buildRouteUrl function) and it is not possible to use this function from the bindings. If we place it in the _dotvvm namespace, it would be possible to create another controls which build routes pretty easily.
• Someone also brought an idea that the format function could be instance, so the binding would look like this value: "Test {0} {1:yyyy/M/d}".Format(Id, CreatedDate)

Other ideas?

[tomasherceg]

OK, let’s split this to these things:

• We’ll support string.Format in bindings and keep the syntax as is. We can also support the $ operator for string formatting.
• We’ll think about the extensibility of bindings, so anyone can add custom alias (like _dotvvm) and place there custom functionality. We’ll need this later for the REST API integration and other features.

[Mylan719]

I personaly would prefer both string.Format syntax and $"" syntax sugar. Implementing string.Format function to be translatable to javascript is easy and it would serve as en example of how dotvvm can be extended by implementing custom function to javascript translators. I like this approach because it is the most general solution and there is plenty of space for future extendability should we or custommers decide they need it. @darilek I like the $"" because I don’t think it would be that hard to implement. The parser is pretty nice and clean so I think it to be that much of a problem. Plus it’s very convinient 😉 @tomasherceg I think starting dotvvm ‘keywords’ with underscore is a good idea to make it clear they are special objects and avoid conflicts or comfusion with other objects as it has been pointed out. However I don’t really like the idea of _dotvvm keyword as some kind of magic box for the few selected funtions that we decide to support. I find it way more confusing than calling those funtions in context where they belong and where they would be expected eg. string.Format. I agree with @exyi said. Linq always complains about every function that it is not translatable to SQL. Message “Function is not translatable to javascript.” I belive won’t scare anyone, specially if they can implement the translator for it themselves. But most of the the time I write tooling not actual markup so my view is… affected 😃