Skip to content
This repository has been archived by the owner on Jan 31, 2020. It is now read-only.

Passing variables to JavaScript from a controller #75

Open
GeeH opened this issue Jun 28, 2016 · 1 comment
Open

Passing variables to JavaScript from a controller #75

GeeH opened this issue Jun 28, 2016 · 1 comment

Comments

@GeeH
Copy link
Contributor

GeeH commented Jun 28, 2016

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:

  • 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));

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


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 😃


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
Copy link
Member

This repository has been closed and moved to laminas/laminas-view; a new issue has been opened at laminas/laminas-view#21.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants