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