Liferay 上 Portlet 开发方法的建议
我们正处于评估一些 portlet 开发框架的阶段。截至目前我知道以下 3 个选项。我想知道您与他们和其他人的经验
- Struts 2
- Spring Portlet MVC
- Liferay 6.x MVC 框架
请尝试分享以下领域的优点/缺点以及您认为重要的
- 内容 开发速度
- 维护
- 与地理分布式团队一起开发的简易性
请建议任何其他可以替代的框架，但有一些优点/缺点
We are in the phase of evaluating some of the frameworks for portlet development. As of now I know of below 3 options. I would like to know your experiences with them and others
- Struts 2
- Spring Portlet MVC
- Liferay 6.x MVC Framework
Please try to share Pros/Cons in following areas along with what you think is important
- Speed of development
- Maintenance
- Ease of development with Geo Distributed teams
Please suggest any other frameworks which can be used as alternative with some pros/cons
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从我的角度来看，使用 MVCPortlet 和 JSP（不使用 Spring-mvc 或 Struts）仅适合简单的 portlet。如果开发人员还没有完成 Portlet，我肯定会至少尝试一个示例 Portlet，看看它是如何工作的。
使用 Struts 的唯一优点是 Portal 本身大量使用它，因为 spring-portlet-mvc 相对较新。这样你就可以从各种例子中学到很多东西。否则，据我所知，该技术正在消亡（关于 portlet 开发），如果您还没有使用过 Struts，那么更好的选择是使用 spring-portlet。我使用 spring-portlet 已有一年多了，我必须说，我对它与 portlet 容器的集成程度以及其中实现的功能感到惊讶。你几乎可以像 spring-mvc（servlet 规范）一样做所有事情，除了一些我发现多余的小支持。
发展速度
了解 spring-mvc 的经验丰富的开发人员只需几个 spring 控制器即可创建强大的应用程序。
维护
spring 的源代码量明显少于 struts。 Spring-portlet 已经实现了 268 个 JSR，因此它节省了一些解决方法。
通过地理分布式团队轻松开发
我感觉您想要做一些更大的事情，因此请向开发人员询问他们使用 Spring 和 Struts 的经验并做出选择。不管怎样，Liferay 是一个相当强大的门户解决方案，“学习”它并找到正确使用它的方法比如何开发 portlet 更重要。
还对开发人员的 Javascript 知识感兴趣。如果他们不太了解 JS 或者你没有前端开发人员，我可能会尝试 Vaadin 或 GWT portlet。然而，Liferay 有非常好的客户端支持，你会发现很多事情可以在 Liferay 的客户端完成。 JSP 标签库提供了大量的动态行为，而构建在 YUI 之上的 Alloy JS 框架为您提供了一个良好的环境，并且使用起来并不困难。
编辑：Struts 与 Spring 的比较是关于 portlet 规范，其中（我认为）struts 支持是老式大众汽车，spring 是宾利大陆 gt :-)
另外：Liferay portlet 开发的关键工具是所谓的 ServiceBuilder，它是代码生成器，根据域模型和元数据生成持久层、远程服务层的重要部分。如果您选择使用它，您的 portlet 将自动基于 Spring。我建议使用它，因为一旦你尝试了，你就不会放手。例如，创建从客户端到远程服务的 Ajax 调用只需 2 分钟即可完成设置、调用它们甚至获取返回值。 Hibernate 设置已完全优化，在运行 servicebuilder 后即可使用。还有很多很多。
From my point of view, using MVCPortlet and JSPs without Spring-mvc or Struts is suitable enough only for a simple portlet. I would definitely try at least a sample portlet to see how it works if developers haven't done portlets.
The only advantage of using Struts is that the Portal itself is heavily using it because spring-portlet-mvc is relatively new. So that you can learn a lot from variety of examples. Otherwise the technology afaik is dying (regarding portlet development) and if you haven't been working with Struts, the better option for you would be go for spring-portlet. I've been using spring-portlet for more than a year, and I must say that I was amazed how well integrated it is into portlet container and what features are implemented there. You can do practically everything as with spring-mvc (servlet spec), except for some minor support that I found redundant anyway.
Speed of development
an experience developer that knows spring-mvc can create a robust application with only a few spring controllers.
Maintenance
The amount of source code is significantly lesser with spring then struts. Spring-portlet has implemented 268 JSR, so that it saves couple of workarounds.
Ease of development with Geo Distributed teams
I sense you are going for something bigger, so that ask developers about their experience with Spring and Struts and make your choice. Anyway, Liferay is a pretty robust portal solution and to "learn" it and find a way to use it properly is more important issue than how to develop portlets.
Also be interested in developers knowledge of Javascript. If they don't know JS much or you don't have front-end developers, I would probably give a shot to Vaadin or GWT portlets. However Liferay has a very good client-side support and you'll see that a lot of things can be done on client-side in Liferay. JSP tag libraries provides a significant amount of dynamic behavior and Alloy JS framework that is built on top of YUI provides you with a nice environment and it is not hard to use.
EDIT: The comparison of Struts vs. Spring is regarding portlet specification, where (my opinion) struts support is an old Volkswagen and spring is Bentley continental gt :-)
ALSO: The key tool for Liferay portlet development is so called ServiceBuilder, which is a code generator, that generates a significant part of your persistence layer, remote service layer based on domain model and metadata. If you choose to use it, your portlet is automatically Spring based. And I'd recommend to use it, because once you try it, you won't let it go. For instance, to create Ajax calls from client-side to remote services is a question of 2 minutes to set it up and be able to call them and even get the return value. Hibernate setup is fully optimized and ready to use after you run servicebuilder. And much, much more.
这真的取决于你的要求，因为liferay MVCPortlet只是javax.portlet.GenericPortlet的简单子类，我不认为这是一个像Strut 2或Spring MVC这样的Web框架之间的公平比较。
我建议对 168 和 168 位用户使用 Spring MVC 或 Struts 2。 268 JSR portlet 如果您想要跨 portlet-容器的可移植性或者如果您有更复杂的表示需求，您应该随处找到这两个框架的优缺点列表。
如果您的要求非常简单，那么请使用 liferay MVCPortlet 甚至 JSPPortlet。
It's Really depend on your requirements, since liferay MVCPortlet are just simple sub-classes of the javax.portlet.GenericPortlet, i dont think it's a fair comparison between web framework such as Strut 2 or Spring MVC.
I suggest using Spring MVC or Struts 2 for 168 & 268 JSR portlet if you want cross portlet-container portability or if you have more complex presentation requirements, you should find a list of the pro and cons of the two framework everywhere .
If you requirement are very simple then go with liferay MVCPortlet or even the JSPPortlet.
我使用过 2) 和 3)，但没有使用 1) - 我不喜欢 Struts。
Spring MVC 为您提供 Spring 的强大功能，并无缝插入 Spring 后端，并允许连接到 Liferay Spring 服务。 假设您正确使用 MVC 并将
Controller关注点分离到单独的Action类中，那么这是一个非常可扩展且灵活的选择，并且与 Liferay 结合使用时效果很好。Liferay 的 MVCPortlet 提供的灵活性要少得多，但如果使用得当，它仍然具有高度可扩展性，并且是一个非常有用的选择。它还与 Liferay IDE/Liferay Development Studio 相结合，在开发过程中提供好处。如果您能够参加 Liferay 开发人员培训，那么第 2 天会有广泛的覆盖范围。
总的来说，Spring 具有更大的好处，但也伴随着更大的学习曲线和更大的错误做事的风险，并且在做得不好时会给您带来更大的打击。 Liferay 的 MVCPortlet 做得不好，最终看起来就像普通的 portlet，因此是两害相权取其轻。就我个人而言，我使用 MVCPortlet 来处理小型任务，使用 Spring MVC 来处理大型任务。
在这两种情况下，“做好”都涉及正确使用框架和注释。
Liferay 还支持 Vaardin 并使用它发布了新的 Mail Portlet。我还没有使用过 Vaardin，但确实计划使用它，并且到目前为止已经听到了一些好消息。
I have used 2) and 3) but not 1) - I'm not a fan of Struts.
Spring MVC gives you the power of Spring and plugs seamlessly into a Spring back-end as well as allowing the ability to wire to the Liferay Spring services. Provided you use MVC correctly and separate
Controllerconcerns into separateActionclasses then this is an extremely scalable and flexible choice and works well when coupled with Liferay.Liferay's MVCPortlet provides much less in terms of flexibility but when used properly it is still highly scalable and a very useful choice. It also ties in to the Liferay IDE/Liferay Development Studio which provides benefits during development. If you have access to the Liferay Developer training then there is extensive coverage on Day 2.
Overall Spring has the greater benefits but also comes with the larger learning curve and greater risk of doing things incorrectly and hits you harder when done badly. Liferay's MVCPortlets done badly end up looking like vanilla portlets and as such is the lesser evil. Personally I use MVCPortlets for small tasks and Spring MVC for the larger ones.
In both cases 'doing it well' involves correct use of the framwork and annotations.
Liferay also supports Vaardin and have released the new Mail Portlet using it. I haven't used Vaardin but certainly plan on it and have heard good things so far.
从易于开发的角度来看，我认为 Vaadin 是最好的之一。新的 Liferay IDE 1.2 已经包含 Vaadin 支持，因此可以非常轻松地开始使用。
应用程序维护和 API 也是如此。使用 Vaadin，应用程序代码只是 Java 代码，这使得划分工作和维护现有代码变得容易（OOP 的好处）。
已经有大量 Vaadin 的“附加组件” 演示了 Java 代码如何“组件化”和开发分散到整个组织中。
唯一的缺点是 Vaadin 库与门户中的所有 Vaadin-portlet 共享，这意味着它们应该使用相同的 Vaadin 版本以使部署更容易。
无论如何，我想说非常适合您的需求。
From the ease-of-development point, I think the Vaadin is one of the best. The new Liferay IDE 1.2 already includes the Vaadin support making it very easy to start with it.
The same goes for application maintenance and APIs. With Vaadin the application code is simply Java code and that makes it easy to divide the work, and maintain the existing code (OOP benefits).
Already a good number of "add-ons" for Vaadin that demonstrate how the Java code can be "componentized" and development split across the organization(s).
Only downside comes from the fact that the Vaadin libraries are shared with all the Vaadin- portlets in a portal, which means they should use the same Vaadin version to keep the deployment easier.
Anyway, I'd say quite good match for your needs.