我正在尝试使用 wicket 构建一个简单的应用程序，到目前为止印象深刻。我一直在利用 Component 类来根据用户输入或模型确定页面上元素的行为。我看到组件模型与 JSF 的相似之处，但发现检票口生命周期更易于管理。
我无法理解的是必须为页面上提到的每个 wicket:id 添加每个组件到树中，尤其是对于没有任何孩子的。当树已经在标记中有所定义时，必须在 java 代码中构建树似乎很繁重。我错过了什么？
编辑
我应该举个例子。我有一个输入框的标签，在某些情况下我希望能够修改它。95% 的时间，我在标记中为标签所拥有的文本和属性都可以。
简短回答：是的，您必须添加它们。
长答案：您可以创建自定义代码来执行此操作，但我怀疑这是否值得。
使用 JSF，您可以使用非 html 标记，该标记具有与之关联的一种组件类型（例如，h:inputText对应于类HtmlInputText），因此它知道要实例化哪个类。
使用 Wicket，HTML 文件仅包含（除了少数例外）HTML 标记，并且您必须为wicket:id添加到标记的每个标记的标记实例化一个具体组件，因为它无法确定是否<span wicket:id='xyz'>表示 a Label、 a FeedbackPanel、 a WebMarkupContainer，或一些自定义组件。
使用 JSF，您可以在标记中执行 Wicket 中的 Java 代码操作，即构建组件树、将组件绑定到属性以及处理事件。它将所有内容保存在一个文件中（您不必为每个模板文件创建一个类），它有很多很多缺点（有些人可能认为它有一些优点，我离题了）。
您的页面绝不仅仅是一个什么都不做的简单表单。您想要转换和验证输入，想要处理提交，想要使用 Ajax 更新组件。使用 JSF，您可以在（不可编译、类型不安全、工具不良、不可重构）模板中完成所有这些工作，从而使其因表达式、配置标签和 - gawd forbid - 业务逻辑而变得臃肿。
如果 Wicket 对此提供支持（而且，它具有您自己构建此附加组件所需的灵活性），您将不得不向标记、声明要实例化的类、要更新的模型、要执行的验证等，损害了框架的两个优点、干净的 HTML 模板以及视觉和逻辑之间的清晰分离。
Apache Tapestry是一个尝试在模板中做更多事情，同时又比 JSF 不那么臃肿的框架（这并不难）。但是从它的教程中可以看出，您最终仍然不得不使用非标准标签并遵循任意约定将模板绑定到代码（您可能喜欢它，但如果是这种情况，您有baaad味，抱歉： P)。
我有一个输入框的标签，在某些情况下我希望能够修改它。95% 的时间，我在标记中为标签所拥有的文本和属性都可以。
您可以尝试将标签的内容包装在模型中，将该标签包含在容器中并重新绘制容器 ( target.add(container);)。
您应该添加它们。wicket 最强大的功能之一是允许您制作可重用的组件，尤其是 html 组件。
建造房屋的方法有上百万种，但大多数人不会考虑从头开始建造厕所、浴缸和玻璃窗。当你可以用比建造它更少的钱买一个厕所，而且你不可能生产出比你在商店里买到的更好的厕所时，为什么要自己建造一个厕所呢？以同样的方式，大多数软件工程师都试图重用软件模块。“制造或购买”决策不仅仅包括模块是否可用；通常，重用软件模块更便宜，并导致更健壮的系统。重用软件还意味着您不必一遍又一遍地编写相同的功能。（wicket in action :manning）
所以要有一个可重复使用的检票口页面，检票口只需要一个 html 页面来显示它的组件层次结构或它们的位置。这些组件的类型和模型留给程序员。