Geek Answers Handbook

Javascript recommendations - using server-side values

Over the past few years, I have always used a hidden <input> field on the client side to store the value on the server side and use it on Javascript ground.

For example, let's say I need an Ajax timeout value from my application configuration.

I would probably save it in my JSP:

<input type="hidden" id="ajaxTimeout" value="${serverValue}" />

and then use it so that my AJAX call lives in an external file:

 $("#ajaxTimeout").val()

Today I discussed this, and it has been suggested that it is better to store values ​​that will be used only by Javascript in HTML <meta> tags.
Does it matter? Is there a preferred way to get server-side information that should only be used in Javascript?
I understand that if the hidden input field is not part of the form, then it is safe enough to store the value, since it will not be attached to any requests. Having said that, I always thought that it was really a cue ball.

Thoughts?

:: EDIT ::
Two fantastic answers:

+7
javascript html client-side server-side hidden-field
source share
4 answers

We personally do something like this:

 var options = { selector: '#divId', serverSideVariableHere: <%=AspNetProperty %>, anotherServerSideVariableHere: <%=AspNetPropertyTwo %> } var viewModel = new KnockoutViewModel(options); ko.applyBindings(viewModel, $(options.selector)[0]);

This is just an example of using KnockOut JS, but this idea can be expanded to any JavaScript library that you decide to use (or not;))

Then we pass these parameters for their use, for example, for ViewModels knockouts or any other. This way, our JavaScript remains testable, and we can pass any values ​​that we want to test.

+3
source share

In addition to the usual old object literals mentioned in other answers, if the value you want to pass to the client is associated with a specific DOM element (or there is a DOM element that is a logical object whose value is), you can put the value in the data attribute :

 <div id="videoplayer" data-startplayingat="1:02">HTML Content</div>

This is available as the full data-startplayingat , or in modern browsers there is a dataset attribute. Syntax jQuery $('#videoplayer').data('startplayingat') .

The official W3C data attribute specification explains all of this.

Here are some interesting points:

  • The name must not contain uppercase letters and must be compatible with XML.
  • The dataset attribute converts a dash, so the name like start-playing becomes startPlaying .

One potential drawback of the object literal method (which I like and used myself) is that if you want an object in a .js file, then usually static javascript files should run through your dynamic parser, which will cause a potentially small (but still existing ) loss of performance. Putting an object declaration in the <script> in the HTML file works around this, but then you may have problems with the order in which the script is loaded.

+4
source share

Using the meta tag for anything other than browser metadata, “instructions,” is nothing more than a hacked IMO.

I would think about storing the JavaScript data where it belongs - in JavaScript using JavaScript object literals.

+1
source share

I strongly prefer JSON fragments in data- attributes. This allows you to combine them into the corresponding HTML element, and you do not pollute the global Javascript namespace or do not need to generate additional code to handle the names otherwise. Combined with server-side JSON serializer, this minimizes the need to manually reset anything in your values.

(I also have Thing ™ tags against <script> with content in general. Viewing and sharing logic and all that.)

+1
source share

More articles:


All Articles