Spring Portlet 与 Liferay 服务器还是 Websphere Portlet Factory？
有什么建议可以将 Spring Portlet 与 Liferay 服务器或 Websphere Portlet Factory 结合使用吗？我假设 Websphere portlet 工厂解决方案加快了 portlet 开发，但从维护的角度不确定。有使用这两种技术堆栈的个人经验吗？
附加信息：我们对 Spring MVC 有很好的了解，并且我们已经拥有 Websphere Portlet Factory 的企业许可证。
Any recommendation to to go with Spring Portlets with Liferay server or Websphere Portlet Factory? I am assuming Websphere portlet factory solution expedites portlet development BUT NOT sure from maintenance point of view. Any personal experience utilising these two technology stacks?
Additional information: We have good knowledge of spring MVC and we already have corporate license for Websphere portlet factory.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据我的经验，WebSphere Portlet Factory 可能适合将大量千篇一律的 Portlet 组合在一起，但调试起来却很糟糕。您无法直接访问它生成的代码，因此，当您看到该代码中的堆栈跟踪时，很难弄清楚发生了什么。
此外，您最终会非常受限于 WPF 范式内的任何内容，并且当您必须在其范围之外执行某些操作时，事情会变得很困难。使用 Spring Portlet MVC，您可以获得更大的灵活性，包括您所使用的技能可以在严格的门户上下文之外应用的优势。
In my experience, WebSphere Portlet Factory might be alright for putting together a lot of cookie-cutter portlets, but is awful to debug. You don't have direct access to the code that it generates, so, when you see stack traces in that code, its difficult to figure out what's going on.
Moreover, you end up being very limited to whatever that within WPF's paradigm, and things get tough when you have to do something outside of its boundaries. You get a lot more flexibility with Spring Portlet MVC, including the advantage that the skills you are using have application outside of the strict, portal context.
任何门户框架的问题在于，每当您冒险尝试 JSR 168 之外的内容时（并且您会想要这样做），它们都会将您锁定在自定义扩展中。
我认为您可以使用 Liferay 最大程度地减少锁定。
另一个建议是完全放弃 portlet，而使用 HTML、CSS 和 Ajax。这样您就不会被锁定到某个供应商。
Portlet 是 20 世纪 90 年代的产物。他们到底想买什么给你？
The problem with any portal framework is that they lock you in with their custom extensions whenever you venture outside JSR 168 (and you'll want to).
I think you'll minimize lockin with Liferay.
Another suggestion would be to forego portlets altogether and use HTML, CSS, and Ajax. You won't be locked into a vendor that way.
Portlets are so 1990s. What are they really buying you?