在 Javascript 中编写 HTML 的良好实践

发布于 2024-08-18 22:21:14 字数 314 浏览 2 评论 0原文

我想知道人们是否对动态生成 HTML 的最佳方法有强烈的意见,特别是对于基于 Ajax 的应用程序。

您是否只是使用服务器端脚本创建 HTML 代码,然后将其发送到页面,或者只是返回一个 JSON 字符串并让 Javascript 完成这项工作。

在我个人看来,第一种方法将表示层与逻辑联系得太多,使得更改变得更加困难,维护起来也成为噩梦。第二种方式虽然是我的首选方法,但当项目复杂性增加时,维护起来也变成了一场噩梦。

我正在考虑使用 Javascript 模板系统作为另一层,只是为了使代码更健壮且不那么僵化。有人有关于轻量且真正优秀的 JS 模板系统的好主意吗?

I was wondering about this if people have strong opinions about the best way to generate HTML on the fly, especially with Ajax based applications.

Do you just create the HTML code using server side scripting and then send it out to the page or perhaps just return a JSON string and let Javascript do the job.

In my personal opinion, the first way ties the presentation layer way too much to the logic and makes it harder to change and a nightmare to maintain. The second way, although is my preferred method, also becomes a nightmare to maintain when the complexity of the project grows.

I was thinking of using a Javascript templating system as another layer, just to make the code more robust and less rigid. Anyone has good ideas of a light and really good JS templating system?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

遮了一弯 2024-08-25 22:21:14

我也更喜欢带有客户端 HTML 创建逻辑的 JSON 响应。

不幸的是,大多数现实世界的客户端 HTML 编写脚本都已损坏,其中包含许多 HTML 注入缺陷,这些缺陷很容易成为跨站点脚本安全漏洞。我认为,因为您是在与自己的服务器而不是直接与敌对用户对话,所以您在某种程度上是“安全的”,并且在将字符串插入 HTML 时可以在没有正确字符串的情况下逃脱。这当然是无稽之谈。

我总是看到类似:

$('#mydiv').append('<em>Deleted '+response.title+'!</em>');

或:

mydiv.innerHTML= '<p>Renamed to '+response.name+'</p>;

或者 Resig 的微模板 hack,默认情况下不进行 HTML 转义。来吧,朋友们!我们才刚刚开始清理提供服务器端 XSS 服务的损坏 PHP 脚本的遗留问题,现在您想引入一系列全新的客户端 XSS 攻击吗?

叹。这就是弦乐的诱惑。我们认为我们理解它们并且可以随意地将它们组合在一起。但字符串是危险的,具有隐藏的上下文和逃避的要求。如果您必须在客户端生成 HTML,您将需要这样的函数:

function h(s) {
    return s.split('&').join('&').split('<').join('<').split('"').join('"');
}

mydiv.innerHTML= '<p>Renamed to '+h(response.name)+'</p>;

但我个人更喜欢 DOM 方法。与 SQL 参数化一样,使用 DOM 方法通过将原始字符串直接与将使用它们的组件进行对话,从而消除了字符串抛出的问题。好的,DOM 的问题在于它相当冗长:

var p= document.createElement('p');
p.appendChild(document.createTextNode('Renamed to '+response.name))
mydiv.appendChild(p);

但是您始终可以定义辅助函数来减少这种情况,例如:

mydiv.appendChild(makeElement('p', {}, 'Renamed to'+response.name));

(jQuery 1.4 中的新元素创建内容使用类似的样式。)

I too prefer a JSON response with client-side HTML creation logic.

Unfortunately, most real-world client-side HTML writing scripts are broken, containing many HTML-injection flaws that can easily become cross-site-scripting security holes. I think the belief is that because you're talking to your own server rather than directly to a hostile user you're somehow ‘safe’ and can get away without correctly strings when interpolating them into HTML. Which is of course nonsense.

I always see stuff like:

$('#mydiv').append('<em>Deleted '+response.title+'!</em>');

or:

mydiv.innerHTML= '<p>Renamed to '+response.name+'</p>;

or indeed Resig's microtemplating hack, where there is no HTML-escaping done by default. Come on, people! We've only just started cleaning up the legacy of broken PHP scripts serving up server-side XSS, now you want to introduce a whole new massive range of client-side XSS exploits?

Sigh. That's the Lure Of Strings. We think we understand them and can sling them together willy-nilly. But strings are treacherous, with hidden contexts and escaping requirements. If you must generate HTML on the client side you will need a function like this:

function h(s) {
    return s.split('&').join('&').split('<').join('<').split('"').join('"');
}

mydiv.innerHTML= '<p>Renamed to '+h(response.name)+'</p>;

But personally I prefer DOM methods. Like with parameterisation for SQL, using the DOM methods takes the string-slinging out of the equation by talking raw strings directly to the components that will consume them. OK, the problem with the DOM is that it's rather verbose:

var p= document.createElement('p');
p.appendChild(document.createTextNode('Renamed to '+response.name))
mydiv.appendChild(p);

But you can always define helper functions to cut down on that, eg.:

mydiv.appendChild(makeElement('p', {}, 'Renamed to'+response.name));

(The new element creation stuff in jQuery 1.4 uses a similar style.)

莫言歌 2024-08-25 22:21:14

一年前,我们启动了一个新的 Web 应用程序,需要一种在浏览器中从 JSON 数据呈现 HTML 的方法。

我们希望它像 XML/XSLT 转换一样快。

我们对此的回答是 JS 模板引擎 PURE

与大多数 JS 模板库不同,它保持 HTML 不变(根本没有奇怪的标签),并且除了一些符号之外,它不会带来新的语言需要学习,只有 JS 和 HTML。

我的使用方式:

  • 直接在页面中构建静态HTML,
  • 然后一步一步添加JS逻辑,HTML逐渐活起来,
  • 习惯了之后,HTML和JS就可以有安全的独立开发生活了,并且可以分为设计师和 JS 开发人员的工作

+1 year ago, we started a new web app, and needed a way to render HTML from JSON data, in the browser.

We wanted it as fast as an XML/XSLT transformation.

Our answer to that was the JS template engine PURE.

Unlike most of the JS templating libs around, it keeps the HTML untouched(no strange tags at all) and except a few notations, it doesn't bring a new language to learn, only JS and HTML.

The way I use it:

  • Build the static HTML directly in the page
  • Then add the JS logic step by step, and the HTML becomes alive progressively
  • Once you get used to it, both HTML and JS can have a safe separate development life, and can be split between a designer and a JS developer job
背叛残局 2024-08-25 22:21:14

我们有一个系统,其中大量数据以 JSON 形式从服务器传递,然后通过客户端的 JavaScript 模板引擎进行处理。在.Net 4.0(甚至可能是3.5 sp1,我不确定)中,这可以使用 客户端模板

我更喜欢传递 JSON 而不是发送 html。将数据和视图分开总是好的。

We had a system where a lot of data was being passed as JSON from the server and then handled through a javascript templating engine on the client side. In .Net 4.0 (maybe even 3.5 sp1, i am not sure), this can be done using Client Templates.

I would prefer passing JSON over sending html. Its always good to keep data and view separate.

没有伤那来痛 2024-08-25 22:21:14

如果你想保留 MVC 框架,你应该让你的模板框架来做模板。
AJAX 应该只执行服务器请求,该请求执行所有数据库和业务逻辑,然后将 URL 返回到应该加载的模板。

If you want to preserve the MVC framework, you should let your template framework do the templating.
The AJAX should only perform the server request, which performs all DB and business logic and then returns the URL to the template that should be loaded.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文