如何使用可从 Javascript 访问的 HTML 发送值?
通常,网页上的 JavaScript 需要能够访问服务器上已知的变量。例如,用户的用户名。假设我们不想发出 JSON/XML 请求,因为这会不必要地增加复杂性以及页面点击次数。我们希望将数据与 html/Javascript 一起发送。
发送数据的一种方法是将其注入 Javascript。
var x={{username}};
另一个想法是在头部创建一个元项并将数据存储在那里,然后使用 jQuery(或等效的)来检索它。
这些方法中的哪一种比另一种更好,或者我应该考虑其他方法吗?
Often the Javascript on a webpage will need to be able to access variables that are known on the server. For example, the user's username. Suppose that we don't want to make a JSON/XML request as that would increase the complexity unnecessarily and also the number of page hits. We want to send the data along with the html/Javascript.
One way to send the data would be to inject it into the Javascript.
var x={{username}};
Another idea would be to create a meta item in the head and store the data there and then use jQuery (or equivalent) to retrieve it.
Is either of these methods preferable to the other or are there any other methods that I should consider?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我不认为有一个正确的答案,当然我在这个问题上听到了很多相互矛盾的意见,但从你提到的两种方法中选择我会选择将值注入 JavaScript,因为我发现它更容易。
但是,既然您询问了其他建议,您可以将这两种想法结合起来:您的服务器端代码可以只在
这种方法还有一个额外的优点,即服务器端代码本质上只是生成 JSON(如果直接包含在页面源代码中,它将成为对象文字),因此如果当您稍后决定开始使用一些 Ajax 时,您就已经差不多成功了。
I don't think there's a single right answer, and certainly I've heard lots of contradictory opinions on this subject, but choosing from the two methods you mention I'd go with injecting the values into JavaScript because I find it easier.
But since you asked for other suggestions you can kind of combine the two ideas: instead of meta items, your server-side code can just insert a single
<script>
element in the<head>
to store the data in a variable that can then be accessed directly from any of your other scripts (including scripts in multiple source files). You can stick all of your data in a single object to avoid lots of globals:This approach has the added advantage that the server-side code is essentially just producing JSON (that becomes an object literal if included directly in the page source) so if you later decide to start using some Ajax you'll already be almost there.
我只会在头部有一个元素,它声明一个包含您的信息的命名良好的全局对象。像这样:
最上面的两行只是初始化你的全局对象。由于它是全局的,我们使用“blah”来命名它。
I would just have a element in the head which declares a well-named global object containing your information. Something like :
The top two lines just initialise your global object. Since it's global, we use "blah" to namespace it.
你所建议的完全没问题。例如,CoffeeScript、Underscore.js 和 Backbone.js 的创建者 Jeremy Ashkenas 建议在 骨干文档
What you are suggesting is totally fine. For example Jeremy Ashkenas, creator of CoffeeScript, Underscore.js and Backbone.js suggests to do exactly the same in Backbone docs
我认为这个问题有点复杂,因为根据我的经验,您很少依赖具有帐户、用户权限等的网站的静态/预创建的 HTML 页面。
通常,这样的网站/应用程序依赖于某种“服务器页面”技术 - ASP、JSP、PHP(或通过 AJAX 请求管理所有这些) - 这将允许您编写某种类似于以下内容的标签/服务器代码
<%=request.getAttribute("userName")%>
- 当服务器编译/解释时,会将您的用户名注入到页面中您想要的位置。如果由于某种原因,您声称您的应用程序中情况并非如此,并且您向用户提供了纯粹的预创建或静态 HTML - 那么,您实际上必须执行以下操作之一:
1.AJAX 请求检索用户名
我认为你的论点是
次数无效。技术使用的正确性应该优先于(也许不存在)性能增益。我也不认为这会增加复杂性,相反 - 您可以将“用户”登录部分分离到模块中并在其他地方重用它。
2.注入JavaScript(或使用元标签)
,我不完全确定你会如何做到这一点并在那之后维护你的页面......
I think that a question is a bit convoluted, since, in my experience, you rarely rely on static/pre-created HTML pages for sites that have accounts, user privileges etc.
Normally, such a site/application relies on some sort of "Server Pages" technology - ASP, JSP, PHP (or manages all of this through AJAX requests) - which would allow you to write some sort of tag/server code similar to
<%=request.getAttribute("userName")%>
- that, when compiled/interpreted by the server, will inject the username for you in the place in your page you intend it to be.If, for some reason, you claim that it's not the case in your application and you deliver pure pre-created or static HTML to your users - then, indeed you would have to do one of the following:
1.AJAX request that retrieves the username
I think that your argument that
is not a valid one. Correctness of use of technology should prevail over (perhaps non-existent) performance gain. I also don't see that as a complexity increase, on the contrary - you could separate the "user" logging in part into a module and reuse it elsewhere.
2.Inject JavaScript (or use meta-tags)
and this one I am not entirely sure how would you do that and maintain your page after that...