search

alexeyrybak / blitz

Blitz templates, template engine extension for PHP
Other
92 stars 42 forks source link

Array/hash literals syntax #25

Closed unkind closed 6 years ago

unkind commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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:

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.