相关内容

返回首页

关于维基路线图的更多信息

发布者：    |       Seam

上周我外出旅行（见图片）时，Gavin 发布了关于维基路线图的文章，没有太多时间进行详细阐述。

我们实际上所说的“维基”是我们正在构建的一个小型平台，用于运行一些网站，最值得注意的是您现在正在查看的网站以及即将到来的/seamframework.org/社区网站。Gavin 已经解释了为什么要从头开始构建，主要原因是我们想用 Seam 来构建。

对我来说，这也是学习如何用 Seam 和 JSF 编写真实应用程序的过程。如果你有典型的 Struts-HttpSession-StatelessFacade-DAO 背景，你将面临一些独特和新颖的挑战。我们经常讨论这个问题，很明显，在运行时引入新的上下文和组件的上下文连接彻底改变了编程模型。这是昨天的聊天摘录

Christian：有些希望用更多模式来解决问题
Gavin：需要时间来培养对什么是对的直觉
Gavin：记得你第一次写面向对象代码的时候吗：)
Christian：问题是，很难理解系统当前的状态
Christian：而这现在变得尤为重要
Christian：而且用命令式编程就已经很痛苦了
Gavin：有趣的观点
Gavin：我不知道你的意思
Gavin：你的意思是没有中心协调？
Christian：当你编写代码时，你会以小步骤推动系统状态的进展
Christian：并且对于每一行，你都需要在脑海中想象它现在是什么样子
Christian：而用 Seam 就不再限于当前的操作堆栈了
Christian：你还需要考虑上下文
Gavin：你不总是需要 这样 吗？
Gavin：即使你没有这些上下文的适当模型
Gavin：我一直发现...
Christian：嗯
Christian：好吧，不是
Christian：会话很容易做 - 即使它最终会有bug
Christian：但是如果你再加入JSF生命周期，页面和会话处理就成了一项挑战

在解决架构问题的众多新方法中，不可避免地，其中一些在长期看来证明是错误的，而另一些则工作得非常好。这也在Seam论坛上变成了常见问题，因此我们作为开发团队需要为Seam用户提供更多指导（可能还需要一个模式目录）。

作为一个项目，Seam现在已经超过两年历史了，Gavin第一次在JBoss内部展示的演示文稿——我相信当时很多人并不理解他想表达什么——可以追溯到2004年的一次开发者会议。所以好消息是，一些明显的设计模式已经浮现出来，我们只需要将它们正式化。还有一些仍然需要讨论。

例如，运行这个网站的代码大约有130个类和50个待办事项。大多数待办事项并不是小问题，而是类似这样的

    @Observer("Wiki.started")
    public void scanForSearchSupportComponents() {
        log.debug("initializing search registry");

        // Fire an event and let all listeners add to the given collection
        // TODO: Is this smarter than PreferenceRegistry scanning approach?
        Set<SearchSupport> searchSupportComponents = new HashSet<SearchSupport>();
        Events.instance().raiseEvent("Search.addSearchSupport", searchSupportComponents);

在部署和启动后，这个扫描应用程序空间，并找到所有想要与平台全文索引/搜索功能集成的组件（基于Hibernate Search与Lucene的优秀集成）。它是通过一个注册表来完成的，在启动时触发一个事件，任何想要注册的组件都会将自己添加到作为事件负载传递的集合中。

我们需要类似的功能来处理偏好设置，任何带有自定义属性集的组件都需要被了解。但我在这里使用了完全不同的方法

    @Observer("Wiki.started")
    public void scanForPreferenceComponents() {
        log.debug("initializing preference registry");

        // Register the meta model by scanning components with @Preference annotation
        String[] boundNames = Contexts.getApplicationContext().getNames();

        for (String boundName : boundNames) {
            if (boundName.endsWith(".component") && !boundName.startsWith("org.jboss.seam")) {
                Component component = (Component) Contexts.getApplicationContext().get(boundName);

                if (component.getBeanClass().getAnnotation(Preference.class) != null &&
                    !preferenceComponentsByName.containsKey(component.getName())) {

                    log.debug("Registering preference component: " + component.getName());

这里发生的情况是，我从应用程序上下文（Seam在这里注册组件元数据）中获取所有组件，找出哪些有@Preference注解，然后为注册表构建自己的元数据。我认为事件/监听器方法更加优雅。我认为许多应用程序需要一个应用程序级别的元数据注册表，这也在论坛上经常被提到。那么，这个模式将是什么样子，哪些变体是好的实践，哪些是不好的实践呢？

附言。如果您想尝试这个应用程序或只是查看代码——请注意，上面的示例应该清楚地表明它并不完美——以下是一些提示：它是在LGPL许可下发布的，您可以在Seam 2.0包的examples/wiki/目录中找到。您可以在此查看Seam 2.0包，或从Seam CVS获取。我们有一个单独的JIRA组件，名为Wiki，用于提交任何错误或改进报告。

回到顶部