当（仅）使用模板系统时，我应该如何管理子模板的 CSS、javascript 等？
过去，在使用不同语言的不同模板系统时，我也遇到过同样的问题，所以首先，
我想使用子模板
来包含某个 UI 组件，该组件可能会出现在多个网站的不同位置。不同的页面。此 UI 组件需要某些 CSS 和 JS 文件。
我想用 CSS 和 JS 资源做正确的事情，据我所知，从广义上讲，就是 a) 尽可能多地组合 b) 尽可能缩小 c) 把我能做的放在一起我的标记的末尾，这样浏览器就不必等待它们加载后再显示内容。
因此，如果我有各种不同的 UI 组件，以及网站不同部分中的不同标题和侧边栏，它们都需要自己特殊的 CSS 和 JS 才能正常运行，那么我通过以下方式管理它们的最佳方法是什么？模板系统使最终标记尽可能小且组织良好？
我的具体情况是，
我正在一个大型遗留 PHP 网站上工作，为了让原作者相信，开发可能在 MVC 成为真正主流之前就开始了，并且在有如此多的框架选择之前就已经开始了。使用。因此，没有一致的 MVC 框架，没有路由，没有模板（也没有 ORM，但这个特定的诅咒在这里并不相关）。
我将不得不让事情继续下去，消除错误并添加一些新功能，直到完全重写可用为止，所以我试图在进行过程中为事情注入一些理智。
最简单的起点似乎是视图层，我在其中使用 TinyButStrong。可以在此处找到其子模板的示例，但是就像我说的，我认为这是一个非常普遍的问题。
我考虑过的事情
有了一个更集成的框架，我希望能够做一些类似 $view->add_js($foo) 的事情，但是过渡到一个成熟的框架是其他什么当我尝试保持现有代码库适航时，人们正在做。甚至没有真正足够一致的文件组织来手动滚动这样的东西。
目前，我能想到的最好的办法是在输出之前从视图中创建一个 DOMDocument，并在以下位置操作 和
非常感谢您的投入。
I've had this same question when working with different templating systems in different languages in the past, so first,
The general question
I want to use a sub-template to include a certain UI component which might appear in different places on a number of different pages. This UI component requires certain CSS and JS files.
I want to Do The Right Thing with CSS and JS resources, which, as far as I know and in broad terms, is to a) combine as many as possible b) minify as much as possible and maybe c) put what I can at the end of my markup so the browser doesn't have to wait for them to load before displaying content.
So, if I've got various different UI components, as well as different headers and sidebars in different sections of the site, which all require their own special CSS and JS to function correctly, what's the best way for me to manage them through a templating system so that the final markup is as small and well-organised as possible?
Specifics of my situation
I'm working on a large legacy PHP site, on which, to give the original authors the benefit of the doubt, development may have begun before MVC became really mainstream, and before there were so many choices of frameworks around to use. So there is no consistent MVC framework, no routing, no templating (no ORM either, but that particular curse isn't as relevant here).
I'm going to have to keep things ticking over, squashing bugs and adding a few new features until a complete rewrite is usable, so I'm trying to breathe some sanity into things as I go along.
The easiest place to start seemed to be the views layer, for which I'm using TinyButStrong. An example of their sub-templates can be found here, but like I said, I think this is a very general question.
Things I've considered
With a more integrated framework I'd like to be able to do something like $view->add_js($foo), but transitioning to a full-blown framework is what other people are doing while I try keep the existing codebase seaworthy. There isn't even really enough consistent organisation of files to roll something like this by hand.
At the moment the best thing I can come up with is making a DOMDocument out of the view right before it's output and manipulating <link> and <script> tags at that point. I don't know if that's a bit crazy though. Given the generality of the problem I'd like to think that there's a known sensible way to go about it.
Many thanks for your input.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
读者很难知道你的代码库可以做什么或不能做什么。处理这种情况的常见方法是将参数传递给视图模板，然后模板可以包含条件块或包含基于参数的子模板。这不需要成熟的框架，独立的模板引擎就可以做到。如果您的模板引擎支持继承，则有一个很好的模式可以处理模板中的资源 - 请在此处查看例如 http://symfony.com/doc/2.0/book/templatating.html。
为每个请求操纵 Dom 来处理这种事情似乎有点不正统。
It's hard for the reader to know what can or cannot be done with your code base. A common way to handle this situation would be to pass parameters to the view template, and the template can then include conditional chunks or include sub-templates based on your parameters. This does not require a full-fledged framework, a stand-alone template engine should do. If your template engine supports inheritance there is a nice pattern for handling assets in your templates - check here for example http://symfony.com/doc/2.0/book/templating.html.
Manipulating the Dom for each request to handle this kind of thing seems bit unorthodox.
在这种情况下，您想要的是某种形式的模板继承；也就是说，子模板可以访问“父”模板中的区域，并且可以编辑或替换这些区域中的内容的技术。使用此功能，可以将通过子模板包含的组件所需的 CSS 和 JS 添加到父页面的
元素中。在 Twig 中，这是通过使用命名块来实现的。首先，创建父模板（或布局，如 Twig 中的名称），例如index.html.twig。您可以在其中包含一个命名块，例如
{% block myCss %}。接下来，要创建子模板，请以行
{% extends ::index.html.twig %}开始模板。然后，子模板中定义的块的内容与父模板中的块同名（在本例中为{% block myCSS %}）将被替换到父模板中。要附加而不是替换父模板中的内容，请使用{{parent() }}包含父模板中已存在的内容。带有代码的示例位于@Basel Shishani 给出的链接。我听说 Twig 是根据 Django 建模的，并且 Django 中的模板继承 看起来非常相似（除了使用
{{ block.super }}而不是{{parent() }}。有一个关于 <一个href="http://www.tinybutstrong.com/forum.php?thr=2837#m12080" rel="nofollow">如何在 TinyButStrong 中实现相同的目标作为更广泛的一点，Assetic 库 看起来是一个非常有前途的解决方案用于管理CSS和JS资产，为了避免重复（例如，多个组件/子模板需要相同的JS文件），启用资产的串联和缩小等等。 tinybutstrong.com/forum.php?thr=2837#m12080" rel="nofollow">其功能介绍提供了更多详细信息。
What you want in this situation is some form of template inheritance; that is, technology whereby a sub-template has access to areas in a 'parent' template, and can edit or replace content in those areas. Using this ability, CSS and JS required for a component included via a sub-template can be added in to the
<head>element of the parent page.In Twig, this is achieved using named blocks. First, you create your parent template (or layout, as it's called in Twig), e.g. index.html.twig. You include in it a named block like
{% block myCss %}.Next, to create a sub-template, you begin the template with the line
{% extends ::index.html.twig %}. Then, the content of a block defined in the sub-template with the same name as a block in the parent template (in this case{% block myCSS %}) will get substituted into the parent template. To append rather than replace content in the parent template, use{{ parent() }}to include content already existing in the parent.An example of this with code is available at the link given by @Basel Shishani. I've heard that Twig is modelled after Django, and template inheritance in Django looks very similar (with the exception of using
{{ block.super }}instead of{{ parent() }}. There is a discussion of how to achieve the same ends in TinyButStrong.As a wider point, the Assetic library looks like a very promising solution for managing CSS and JS assets, in order to avoid duplication (e.g. where the same JS file is required by multiple components/subtemplates), enable concatenation and minification of assets, and more. This presentation of its features gives more details.