Velocity：对于在不同页面上重复多次的 DIV 块，使用 Velocity 宏或 #include(...) 语句是否更好？
我有大约 10 个动态生成的 HTML 标准块，这些块包含在我网站的大部分页面中（信息侧边栏）。
我可以使用 #include 语句或将它们定义为宏，两者都可以。
什么更好？我是 Velocity 新手，正在从 JSP 迁移站点。
为什么要使用其中一种而不是另一种？当无参数的宏（）做同样的事情时为什么要#include？从缓存/内存的角度来看，它们的处理方式有什么不同吗？
I have about 10 standard blocks of dynamically generated HTML that get included on a large percentage of pages on my site (informational sidebars).
I can use #include statements or define them as a macros, both would work.
What's better? I'm new to Velocity and migrating a site from JSP.
Why use one vs the other? Why have #include when a no-arg macro() does the same? Are they handled any differently from a caching/memory perspective?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果它们是静态块（其中没有 VTL 代码），那么 #include-ing 它们作为单独的资源肯定会表现得更好。即使它们是动态的（具有 VTL 代码），您也可以使用 #parse 而不是 #include，并且仍然获得比宏更好的性能。当我得知 #define VTL 块比宏更快时，我什至不会感到惊讶，尽管我还没有对此进行测试。宏很棒而且非常有用，但人们有时会误用或滥用它们。
#parse 和 #include 的缺点是您必须维护更多单独的文件，但这就是卓越速度的代价。 #define 对于不需要参数和/或需要作为引用传递的代码块非常有用，但您应该只在定义它们的模板中直接使用 #define'd 块，否则事情可能会变得混乱。
宏的伟大之处在于它们接受参数并且可以在全局范围内定义，而全局范围是它们表现最好且最有意义的地方。当我有合理的选择时，我通常会尽量避免使用本地宏。当我成功避免使用任何本地宏时，我关闭对它们的支持以获得小幅速度提升。
If they are static blocks (no VTL code in them), then #include-ing them as separate resources will certainly perform much better. Even if they are dynamic (have VTL code), then you can use #parse instead of #include and still get better performance than a macro. I wouldn't even be surprised to learn that #define VTL blocks are faster than macros, though i haven't tested that. Macros are great and very useful, but people do sometimes misuse or abuse them.
The downside of #parse and #include is that you have to maintain more separate files, but that's the price for superior speed. #define is great for code blocks that don't need args and/or need to be passed around as a reference, but you should only use #define'd blocks directly in the template that defines them or things can get confusing.
Macros are great in that they take params and can be defined globally, and globally is where they perform best and make most sense. I generally try to avoid local macros when i have a reasonable alternative. And when i successfully avoid having any local macros, i turn support for them off to get a small speed boost.