Array/hash literals syntax

[unkind]

Let's say you have url(<route>, array <params>) function for the URL generation. By now, you are not able to call it like

<a href="{{ url("user", {"login": user.login}) }}">{{ user.name }}</a>

It would be great to add array/hash literals syntax. I suggest to use JSON-like syntax, i.e. [1, 2, 3] for arrays and {"foo": "bar"} for hashes.

[alexeyrybak]

Hi,

If someone implements this as a patch - I will include this as an option.
I must say that this feature increases a tension to control your app from templates, and I'm personally against this: template is just an HTML with some simple additional syntax, not a real code.
In your example I think it's better to use

<a href="{{ url }}">{{ user.name }}</a>

and give all the control to the code, not to the template.

[unkind]

template is just an HTML with some simple additional syntax, not a real code

It doesn't work in reality, at least in our company. It's all about separation of concerns. As backend dev, I don't care about web presentation as well as I don't care about Android and iOS mobile apps. I provide API for them and they can finish their work on their own. Your approach force me to know about all variables for the client-side, I have no idea why, they can generate URL without me, I don't even know whether they need URL or not.

Furthermore, we don't create web controllers and views (PHP classes) for the new services at all, we create only API controllers; client-side can pull data from API and finish work without requests like "Can you pass user page URL and his avatar URL, please?".

I must say that this feature increases a tension to control your app from templates

Client-side controls my app through API exclusively, all this JavaScript madness and templates is not "my app" and they can do what they want to do. By analogy, iOS app is not my concern. Approach with "light" templates is very painful in reality.

[alexeyrybak]

I understand and partly agree, the only thing I want to mention is this. iOS/Android/WindowsPhone clients are built with a full-stack languages, and I assume that they only know your "generic" API, there's no "view" part in your app that mobile app uses. For web clients your logic sits in JS, and if it was limited only with JS it would be OK - similar to what you have in mobile clients. But you also use logic in templates, and need to couple templates with a PHP template API (url function itself is an example of this coupling). I mean this can work, but I would suggest to have all the logic in JS then (like implement all the url function in JS), and talk to JS via same API as you use for iOS and Android (this is what we try to build in our company).

Nevertheless I agree that the feature might be useful in certain cases and I'll definitely keep this issue.

[unkind]

But you also use logic in templates, and need to couple templates with a PHP template API (url function itself is an example of this coupling)
talk to JS via same API as you use for iOS and Android

There are 2 kinds of API here:

• Domain API of the system like users, albums, messages, etc. This API is about domain (dating site, social network, etc.), web and mobile applications use it for interacting with the system.
• API of the presentation layer itself: Google provides API for the Android devs; Apple provides API for the iOS/Mac developers; we provide API ({{ url() }}, {{ widget() }} and similar functions) for our web client-side developers.

I don't think it's a good idea to put URL generation in the domain API as URLs is a presentation detail and usually it makes no sense for the iOS/Android developers, they have activities/views/screens and own internal concepts without any knowledge about web URLs.