Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7160
User: @bogdanghervan
Created On: 2015-01-27T02:01:15Z
Updated At: 2015-09-16T12:37:21Z
Body
Often at times in the past I needed to pass data to the JavaScript scope from a controller and finally I decided I needed to address this in a consistent way across the projects I worked on (I've seen several ways of doing it, but they were lacking a certain elegance).
In ZF1-based projects I've addressed this by extending Zend_View_Helper_HeadScript with these methods for maximum flexibility and consistency with what ZF1 offers out of the box for regular JS files or stylesheets:
appendVar
prependVar
setVar
offsetSetVar
Here's how it would look in ZF2:
$this->headScript()->appendVar('baseUrl', $baseUrl)
->appendVar('errorMessage', 'User not found')
->prependVar('ids', array(25, 48));
Do you think this could be an addition to ZF2 itself that everyone could benefit from? I could submit a PR if you agree.
Comment
User: @Ocramius
Created On: 2015-01-27T05:09:18Z
Updated At: 2015-01-27T05:09:18Z
Body
I 100% see a good use of this, as we could optimize all variables into a single <script/> block as well.
What I think though, is that you'd first code this as a ZF2 module, and then PR it to the framework once it is mature/production ready.
Comment
User: @Martin-P
Created On: 2015-01-27T15:28:44Z
Updated At: 2015-01-27T15:28:44Z
Body
Can you give a more detailed example when you need this? When I look at the current examples I think data-attributes are a much cleaner way of achieving your goals?
Comment
User: @bogdanghervan
Created On: 2015-02-18T23:17:45Z
Updated At: 2015-02-18T23:17:45Z
Body
Yes, using data attributes is a good solution, thank you for pointing that out. But sometimes, having too many of them can litter the markup code. Also, you would probably need to flatten the data if it's a more complex structure.
Aside from that, data attributes may not work for all cases, if the data you're trying to pass is not exactly bound semantically to objects in your markup. Say you want to pass translations to JavaScript, or map pins (you're a map app!) or something else.
I can no longer handle this proposal at the moment, but it someone else wants to take over, they might be able to use this view helper for ZF1 as a starting point.
Comment
User: @ins0
Created On: 2015-09-15T14:10:22Z
Updated At: 2015-09-15T14:10:22Z
Body
I get into the same situtation when dealing with many javascript vars and this would really an enhancement, also dealing with only a single javascript script tag.
So as @bogdanghervan offered i would start working on this, if everyone is fine with this. :sunflower:
Comment
User: @Martin-P
Created On: 2015-09-15T19:23:50Z
Updated At: 2015-09-15T19:23:50Z
Body
Personally, I think the javascript code needs a cleanup if things like translations are defined as a variable in your javascript code. A translation file would be more logical to me and you would only need a single data-attribute in a tag which selects the language, but perhaps my workflow is different.
Feel free to start working on it if your workflow requires this feature :smiley:
Comment
User: @tasmaniski
Created On: 2015-09-16T08:36:41Z
Updated At: 2015-09-16T08:36:41Z
Body
I had a need for this feature. Eg, sometimes I have something like "JS config", that is dynamic and filled from controller or backend.
Comment
User: @ins0
Created On: 2015-09-16T08:39:10Z
Updated At: 2015-09-16T08:41:34Z
Body
@Martin-P I don't think that we should blame somebodys workflow for this. This Helper could be improved and append every variable within its own script tag (if you don't prepare one javascript string by yourself) feels a bit off. no?
Comment
User: @danizord
Created On: 2015-09-16T12:03:37Z
Updated At: 2015-09-16T12:03:37Z
Body
Nice idea! So I'll finally replace that var stuff = <?= json_encode($stuff); ?>;
But will you put all variables in the global js scope?
Comment
User: @ins0
Created On: 2015-09-16T12:13:50Z
Updated At: 2015-09-16T12:14:10Z
Body
Correct as well a option do define lazy loading javascript files. It would make sense to put all vars in the global scope (as it is right now) - this helper should not be responsible for dealing with scopes. any doubts with this?
Comment
User: @Martin-P
Created On: 2015-09-16T12:24:00Z
Updated At: 2015-09-16T12:24:00Z
Body
@ins0 What I try to point out is when you keep the same separation of concerns in your javascript code as you would in your PHP code I personally don't think you would run into this issue. I think everyone agrees the use of $_GLOBAL in PHP is not done, should it be okay in javascript?
Comment
User: @ins0
Created On: 2015-09-16T12:31:39Z
Updated At: 2015-09-16T12:37:21Z
Body
true but the overall issue still persists - defining each variable in seperated script tags and you're forced to write stuff like this ->appendScript('var foo = "'. $vars . '"') - beside the fact if this is a good decision to asign every variable in the global scope or not. This concern should not be handled by the viewhelper.
If you are willing to write advanced stuff you always can fallback on the capture methods - which will give you full control of your injected script/vars.
This issue has been moved from the
zendframework
repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.htmlOriginal Issue: https://api.github.com/repos/zendframework/zendframework/issues/7160 User: @bogdanghervan Created On: 2015-01-27T02:01:15Z Updated At: 2015-09-16T12:37:21Z Body Often at times in the past I needed to pass data to the JavaScript scope from a controller and finally I decided I needed to address this in a consistent way across the projects I worked on (I've seen several ways of doing it, but they were lacking a certain elegance).
In ZF1-based projects I've addressed this by extending
Zend_View_Helper_HeadScript
with these methods for maximum flexibility and consistency with what ZF1 offers out of the box for regular JS files or stylesheets:appendVar
prependVar
setVar
offsetSetVar
Here's how it would look in ZF2:
You can see the ZF1 helper here: bogdanghervan/zf-append-var.
Do you think this could be an addition to ZF2 itself that everyone could benefit from? I could submit a PR if you agree.
Comment
User: @Ocramius Created On: 2015-01-27T05:09:18Z Updated At: 2015-01-27T05:09:18Z Body I 100% see a good use of this, as we could optimize all variables into a single
<script/>
block as well.What I think though, is that you'd first code this as a ZF2 module, and then PR it to the framework once it is mature/production ready.
Comment
User: @Martin-P Created On: 2015-01-27T15:28:44Z Updated At: 2015-01-27T15:28:44Z Body Can you give a more detailed example when you need this? When I look at the current examples I think data-attributes are a much cleaner way of achieving your goals?
Comment
User: @bogdanghervan Created On: 2015-02-18T23:17:45Z Updated At: 2015-02-18T23:17:45Z Body Yes, using data attributes is a good solution, thank you for pointing that out. But sometimes, having too many of them can litter the markup code. Also, you would probably need to flatten the data if it's a more complex structure.
Aside from that, data attributes may not work for all cases, if the data you're trying to pass is not exactly bound semantically to objects in your markup. Say you want to pass translations to JavaScript, or map pins (you're a map app!) or something else.
I can no longer handle this proposal at the moment, but it someone else wants to take over, they might be able to use this view helper for ZF1 as a starting point.
Comment
User: @ins0 Created On: 2015-09-15T14:10:22Z Updated At: 2015-09-15T14:10:22Z Body I get into the same situtation when dealing with many javascript vars and this would really an enhancement, also dealing with only a single javascript
script
tag.So as @bogdanghervan offered i would start working on this, if everyone is fine with this. :sunflower:
Comment
User: @Martin-P Created On: 2015-09-15T19:23:50Z Updated At: 2015-09-15T19:23:50Z Body Personally, I think the javascript code needs a cleanup if things like translations are defined as a variable in your javascript code. A translation file would be more logical to me and you would only need a single data-attribute in a tag which selects the language, but perhaps my workflow is different.
Feel free to start working on it if your workflow requires this feature :smiley:
Comment
User: @tasmaniski Created On: 2015-09-16T08:36:41Z Updated At: 2015-09-16T08:36:41Z Body I had a need for this feature. Eg, sometimes I have something like "JS config", that is dynamic and filled from controller or backend.
Comment
User: @ins0 Created On: 2015-09-16T08:39:10Z Updated At: 2015-09-16T08:41:34Z Body @Martin-P I don't think that we should blame somebodys workflow for this. This Helper could be improved and append every variable within its own script tag (if you don't prepare one javascript string by yourself) feels a bit off. no?
Comment
User: @danizord Created On: 2015-09-16T12:03:37Z Updated At: 2015-09-16T12:03:37Z Body Nice idea! So I'll finally replace that
var stuff = <?= json_encode($stuff); ?>;
But will you put all variables in the global js scope?
Comment
User: @ins0 Created On: 2015-09-16T12:13:50Z Updated At: 2015-09-16T12:14:10Z Body Correct as well a option do define lazy loading javascript files. It would make sense to put all vars in the global scope (as it is right now) - this helper should not be responsible for dealing with scopes. any doubts with this?
Comment
User: @Martin-P Created On: 2015-09-16T12:24:00Z Updated At: 2015-09-16T12:24:00Z Body @ins0 What I try to point out is when you keep the same separation of concerns in your javascript code as you would in your PHP code I personally don't think you would run into this issue. I think everyone agrees the use of
$_GLOBAL
in PHP is not done, should it be okay in javascript?Comment
User: @ins0 Created On: 2015-09-16T12:31:39Z Updated At: 2015-09-16T12:37:21Z Body true but the overall issue still persists - defining each variable in seperated
script
tags and you're forced to write stuff like this->appendScript('var foo = "'. $vars . '"')
- beside the fact if this is a good decision to asign every variable in the global scope or not. This concern should not be handled by the viewhelper.If you are willing to write advanced stuff you always can fallback on the
capture
methods - which will give you full control of your injected script/vars.