使用 Velocity Macro 创建 UI 组件
使用velocity宏来创建UI组件是个好主意吗? 性能和代码可维护性如何
例如,
<input type="text" name="$name" value="$value" />
,我们将编写
#text($name $value)
Is It a good Idea to use velocity macro to create UI components,
what's about performance and code maintability
for example, in place of
<input type="text" name="$name" value="$value" />
we will write
#text($name $value)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您想隐藏分支逻辑或长 html,这当然很方便。
假设您想要一个通用的导航按钮格式化程序,您只需要更改一处代码。
恕我直言,对于重构来说,它更容易,对于可移植性和新团队成员来说,可能更难。
这是我使用的示例代码来说明这一点:
It is certainly convenient if you have branching logic or long html that you want to simply hide.
Suppose you want a generic navigation button formatter, you only need to change the code in one place.
IMHO, For refactoring it is easier, for portability and new team-members, maybe harder.
Here is a sample code I use that illustrate this:
没有“好”或“坏”之分,只有“适合情况”。
除非涉及大量逻辑或大量简化,否则我不会简单地用宏或模板替换标准标签 - 我需要足够的功能来完成额外的工作、额外的时间和额外的认知负荷是值得的。
(“认知负荷”只是意味着,如果我正在查看模板文件,如果我必须查找宏,我将需要更长的时间才能完全理解它在做什么。这不一定是坏事,如果我知道应用程序的代码,这不相关。)
There's no "good" or "bad", there's "appropriate for the circumstances".
Unless there's a lot of logic involved, or a large amount of simplification, I would not simply replace standard tags with a macro or template--I'd need enough functionality to wrap up to make the extra work, extra time, and extra cognitive load worth it.
("Cognitive load" just means that if I'm looking at the template file it'll take me longer to completely understand what it's doing if I have to look up the macros. That's not necessarily bad, and if I know the app's code, it's not relevant.)