问题标签 [html-templates]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
r - R Shiny 基于“html 模板”的应用程序中的 highcharter 集成
上下文
我想使用基于html 模板的高级 UI 创建一个 R Shiny 仪表板。因此，UI 是用纯 HTML 构建的，我使用bootstrap 4 免费模板作为起点。
问题 虽然使用 highcharter 及其闪亮的集成功能可以很好地处理超级基本的 HTML 文件（与上面的教程相同），但一旦我使用引导仪表板主题，图表就不会显示。
我尝试过的
可重现的示例
在这里共享可重现的示例很困难，因为您需要完整的 SB Admin 2 文件夹才能使其工作。基本上这不起作用：
对应的可重现服务器部分：
})
直觉 我猜某处可能存在冲突，或者缺少指向 js 文件的链接，但到目前为止我一直无法找到并解决这个问题
索引.HTML 头
对 JAVASCRIPT 的 INDEX.HTML 调用
评论第一行使 highcharter 工作（但结果其他交互功能被破坏......）
在 GLOBAL.R 中加载的包
会话信息
javascript - 如何在没有 Html-Imports 的情况下打包或导入 Html-Templates
由于 Html-Imports 现在在 Chrome 中已弃用（https://www.chromestatus.com/feature/5144752345317376）并将被删除，我想知道替代方案是什么。
我目前正在使用 Html-Imports 导入 Html-Templates。到目前为止，我只看到两种选择：
- 将所有 HTML 文件捆绑在一个文件中。这也将改善生产中的下载时间，但这会减少封装和模块化。有一个聚合物捆绑器可以通过遍历分离的 HTML 文件中的 HTML-Import-Statements 来完成这项工作。但这意味着，即使将来任何浏览器都不支持 HTML 导入，它们也会保留在我的代码中。
- 使用 XHttpRequests 构建某种模块加载器，并在运行时将模板编入一个 HTML 文件。这将保留封装和模块化，但这对我来说很糟糕，因为我基本上会自己重建导入语句。
有没有一种新的方式来导入 Html 模板？（通过“香草”我基本上是指一种不涉及任何额外工具（如预编译器或捆绑器）的方式）
asp.net-core - 我可以在编译时不知道其名称的情况下填充 websharper 模板的漏洞吗
我是使用 WebSharper 的新手，但我陷入了使用 WebSharper 4 的当前情况：
我有以下 html 模板 (some-template.html) ：
它定义了一个名为 的内容漏洞Content。通常，可以使用以下代码 (F#) 填充它：
在我的场景中，我不知道模板的名称和编译时的漏洞。假设我有一个功能：
我不知道如何最好地处理 (1) - 创建模板，以及 (2) - 定位和填充孔。想到反射，但我想知道是否有更优雅和高性能的方法。
一个更普遍的问题 - 有没有一种动态组合 html 模板站点的好方法？这就是我想要实现的目标，但如果它已经完成，就没有必要重新发明轮子了。如果您也可以向我指出此类资源，我将不胜感激。
javascript - HTML Element versus Javascript Template Literals
Mozilla says Web components consist of three main technologies:
-
Mozilla says Web components consist of three main technologies:
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
And then use this later in JavaScript like so:
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
Mozilla says Web components consist of three main technologies:
-
Mozilla says Web components consist of three main technologies:
Is number 3, "HTML templates", even necessary in light of ECMAscript's Template Literals?
Look at this example I got from James Milner:
Notice how he doesn't use an HTML template, but instead uses an ecmascript template literal to set the innerHTML of the shadowRoot.
After this, he uses querySelector to get internal elements of the shadowRoot and he ultimately adds event listeners to the increment and decrement buttons.
If you were to use a HTML template, instead of an ecmascript template literal, what does this gain you?
Conceptually, I'm struggling to find a situation where I'd prefer an HTML Template Element over an Ecmascript Template Literal.
Please advise.
The template tag is not 'required' for Web Components per se. It probably made more sense when HTML Imports were being pushed, allowing for importing and reusing HTML snippets, but that has since ceased. Here you could have imported a template and reused that.
It's important to note the specifications are designed to be standalone and can be used interdependently of each other also, which makes them versatile. The HTML tag has use cases outside of the realm of Web Components; it's useful because it allows you to define a piece of markup that doesn't render until instantiated via JavaScript later on. Indeed you can use templates without using any of the other specifications (Custom Elements, Shadow DOM etc).
The template tag can certainly be used in conjunction with the other specs. For example, we could have used it in the example shown to arguably make the code less imperative and more markup focused like so:
And then use this later in JavaScript like so:
The downside here is that it would require that the template existed in the DOM prior to the instantiation as it is relying on the #counterTemplate template being there. In some ways this makes the Custom Element less portable, hence why template literal might be more desirable. I haven't tested the performance of both, but my gut tells me that the template would possibly be more performant.
Disclaimer: I wrote the original blog post
dom - 模板中的 css 类 - 效率
如果我创建包含多个 css 类定义的 html 模板元素，然后使用拥有的影子 DOM 将该模板克隆到 1000 个实例中，会发生什么？
我已经尝试过了，我不确定它是否还在内存中创建了 1000 个相同的 css 类定义，这不是有效的。
在将全局样式应用到 Shadow DOM 的正确方法中讨论了样式的复制。是的，所有样式都应用于元素，因此无论是否使用模板创建它们都是重复的。但是类定义呢？它们是在模板实例之间共享还是重复？
python - 在 Django 项目中构建模板的最佳实践是什么？
我知道有很多关于如何构建整个 Django 项目的最佳实践的问题，但我找不到关于如何为 Django 项目构建模板的具体解释。
显然，我刚刚开始学习 Python/Django，我很困惑为什么我找到的大多数教程/示例，模板目录下的目录名称总是与应用程序目录名称相同。
例如：
这实际上来自一个博客：https ://oncampus.oberlin.edu/webteam/2012/09/architecture-django-templates
在上面的应用程序结构中，应用程序gazette/下有templates/目录。反过来，在templates/下，有一个名为gazette/的目录，它与包含它的应用程序目录同名。在这个文件夹下是实际的 html 模板文件。
问题：为什么不能直接把所有的html模板文件放到templates/目录下？如果模板文件夹下有几个目录，我会理解结构的逻辑。但是，我从未从 YouTube 或博客中的任何教程或博客中找到一个显示项目结构的示例，其中模板目录下有多个目录。相反，他们必须将其唯一的目录（在模板下）命名为与应用程序目录相同的目录。
如果您能解释其背后的原理并将我指向任何参考/链接，我将不胜感激。
提前致谢
python - 运行 Bokeh 应用程序的 Flask 服务器：如何从 server_document() 函数生成的脚本中访问绘图
我一直在使用 Bokeh 来绘制一个大型数据库，并使用 Flask 在 localhost 上为应用程序提供服务。总结的代码如下所示：
代码运行得很好，但是当涉及到访问 p1 和 p2 以将其插入到 Jinja2 html 模板中的自定义 div 中时，我不知道如何。html 模板如下所示：
事实上，脚本一个接一个地绘制 p1 和 p2，并且忽略了 Jinja2 for循环（可能是因为我在模板中引用的变量不存在......）。但是，我想将每个图（p1 和 p2）作为参数传递给 render_template() 函数，这样我就可以自由地将它们放在 html 模板上的任何位置，但我不知道如何.
欢迎任何想法。
spring-boot - 控制器类找不到 html 模板
我正在尝试为学校创建 Spring Boot 应用程序，该应用程序使用控制器将书籍从数据库中列出到 html 页面。
就个人而言，我认为问题在于控制器由于某种原因找不到模板。因为当我通过 chrome 导航到想要的模板时，它只在页面上显示“书单”，没有别的。
我尝试创建全新的项目并将代码从我的其他文件复制到新文件，但没有任何结果。
我的控制器类：
我的html模板：
pom.xml 文件：
application.properties 文件：
javascript - 流星反应项目的问题
我使用meteor-reactjs-mongodb 组合开始了一个新项目。我有很多问题，因为我是这些问题的初学者。
1）初始编译时间几乎是 5 分钟。如果您解释如何优化，我将很高兴。
2）我正在使用 html 模板来响应前端。我已经从付费模板中复制了所有依赖项和插件。但它并不像我想要的那样容易。我应该寻找一个反应模板而不是 html 吗？
欢迎您就此事提供所有专业知识。