Passing JavaScript variable names and values from server script (ASP.NET)
What are some good ways to deal with this messy and unnecessary and not very dynamic JavaScript generation:
var <%# JavascriptId %> = new BusinessChart(
'<%# JavascriptId %>',<%# CurrentUserId %>,'<%# ChartId %>'
,'<%# Helper.GetBaseUrl() %>','<%# ChartPath %>'
,'<%# Helper.ResolveUrl("~", true) %>'
);
<%# JavascriptId %>.Init();
I found this other question , but the answers don't seem to address the source of the smell.
I see several specific problems:
- JavascriptId is the name of the variable. Why should I ever, EVER define a variable name on the client side on the server side?
- CurrentUserId never changes for a user ... This is their user id. Same for GetBaseUrl () and ResolveUrl ("~") ... Why should I pass constants all over the place?
- I need to open aspx.cs codebehind file to debug files and not use Intellisense.
I've come up with a couple of ideas for solving the above problems (global Application object declaration, jQuery + class declarations on DOM elements), but I'd love to hear more thoughts on that.
source to share
I don't know if it will solve your exact problem, but this article by Rick Strahl might be interesting .
source to share
You are asking about code smells, so I assume the ambiguity of the code situation is appropriate. What's the deal with BusinessChart, for example. There is a huge amount that we do not know here. But this is what I feel: Only the first number you mention smells really bad to me. It is very strange to indicate this on the server. I suppose there might be a reason for this, but it's hard for me to imagine. There may be good reasons for the CurrentUserID variable. Maybe BusinessChart filters different data depending on the user's role, for example.
As far as GetBaseUrl and ResolvUrl are concerned, this could also be legal. BusinessChart may require a full URL, and GetBaseUrl / ResolveUrl is the central place to ensure that you only need to change the configuration in one place. And why not use the web.config link to do this? Errrr maybe multiple web applications or deployment using these paths and the Helper class gets this url from the shared db, providing one common configuration for multiple applications or deployments.
As far as code usage is concerned, it is sometimes necessary. While it is true that often such dynamic code is not needed, sometimes with complication there is the greatest overall simplicity.
I am trying to question the existing code as you can see. However, I wouldn't be surprised if you find that, as you suspect, all the dynamic code in your example is really useless. I would say your sense of smell seems pretty good! And that the first problem you talk about smells the worst.
source to share
You might want to focus more on data driven JavaScript. Store your data as JSON and leave your code to "encode" things:
// This is the dynamic data part
var charts = [{
Id: '<%# JavascriptId %>',
UserId: <%# CurrentUserId %>,
ChartId: '<%# ChartId %>',
BaseUrl: '<%# Helper.GetBaseUrl() %>',
ChartPath: '<%# ChartPath %>',
HomePath: '<%# Helper.ResolveUrl("~", true) %>'
}];
// This is just code that can be stored away
// in the application static javascript
function initChart(data) {
var chart = new BusinessChart(
data.Id, data.UserId, data.ChartId,
data.BaseUrl, data.ChartPath, data.HomePath);
char.Init();
return chart;
}
Better yet, instead of putting this in an HTML file, write a REST request handler that returns this JSON.
You are now very close to an AJAX application.
source to share