zendframework / zend-view

View component from Zend Framework
BSD 3-Clause "New" or "Revised" License
49 stars 61 forks source link

Passing variables to JavaScript from a controller #75

Open GeeH opened 8 years ago

GeeH commented 8 years ago

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.html


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:

Here's how it would look in ZF2:

$this->headScript()->appendVar('baseUrl', $baseUrl)
                   ->appendVar('errorMessage', 'User not found')
                   ->prependVar('ids', array(25, 48));

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.


weierophinney commented 4 years ago

This repository has been closed and moved to laminas/laminas-view; a new issue has been opened at https://github.com/laminas/laminas-view/issues/21.