Java世界有一个关于门户和portlet如何互操作的JSR-286标准:共享统一网页的软件组件.
似乎有许多门户实现.但是,是否存在可互换的portlet的实时"市场"？从我可以找到的搜索网络,它看起来非常不平衡 - 所有门户网站和没有portlet.这就像是有几十部Android手机而没有应用程序.
如果产品基于JSR-286(或其某些实现),那么企业客户有可能想要添加到门户网站的一堆portlet的可能性是多少？
令我感到震惊的是,大多数企业已经拥有一个类似门户网站的页面,这些页面基于他们选择的业务运行的ERP或CRM产品,甚至可能只是MS Outlook的"今日"页面.因此,如果我发布一个面向企业客户的新产品,并将其设为门户网站(而不是一组portlet),那么我的客户放弃现有IBM/SAP/Oracle门户网站并将我的门户网站用作新主页的可能性是多少？(我猜:不是很好.)如果我将它设置为一组兼容JSR-286的portlet,我的客户是否会有办法托管主机portlet？(我猜:也不好).
最后,JSR-286似乎对HTML + JavaScript非常无声,即门户和portlet如何在浏览器内互操作.这都是关于基于Java的服务器端的东西,定义了一种合作使用URL的方法,这样每个整页刷新都可以路由到正确的portlet.它似乎并不承认现代,丰富的AJAX方法.它只是顺便提到了AJAX.
这篇博客文章(及其下的评论)提供了许多思考的东西,似乎证实了我的怀疑:
专业的实践经验以及上述研究使我得出结论,门户架构缺乏足够的技术优势和区别特征,需要增加接受度.实际上,很少有应用程序可以将自己限制在portlet的孤立和完全不同的功能中,放弃这种程度的架构控制在企业级软件中是不现实的 ......门户架构成为主流技术的机会之窗不仅关闭了,但很久以前关闭了.
所以总结一下这是一个更连贯的问题:在这一点上我将通过构建JSR-286获得什么实际价值？
我的团队一直在使用Node.js,Twitter Boostrap,Mongo DB和Mule为ESB编写仪表板应用程序.
最近,一位高管要求我们改变我们对像Liferay这样的Portal/Portlet容器的方法.
我们团队中的一些人有Liferay的经验,我们对此有非常消极的感受.处理完整页面刷新,portlet生命周期,样式和主题问题以及有限的DBMS覆盖率等问题是我们的投诉列表中的首要问题.
我们看到我们的管理团队来自哪里.他们已经决定,他们希望使仪表板可扩展,轻松或更容易插入其他组.
有没有一个解决方案可以平衡用户的现代Web期望与IT专业人员和负责建立和扩展应用程序的管理人员的企业需求,如Liferay？可插拔小部件在这里很重要.
节点显然是我们的偏好,像Grails这样的东西紧随其后.
谢谢,
我正在尝试在谷歌应用程序引擎上构建一些"portlet服务器".(作为开源)
我想使用JSR168/286标准,但我认为应用引擎的限制将使它介于棘手和不可能之间.
有没有人试图在谷歌应用引擎上运行jetspeed或内部使用pluto的应用程序？
根据我目前对portlet和谷歌应用程序引擎的了解,我预计会出现以下问题:
带有portlet的war文件从部署的角度来看或多或少是一个完整的webapp(是的,我知道没有门户服务器它真的不起作用).war文件可能包含它自己的web.xml等.这使得在app引擎上的部署相当困难,因为这些应用程序彼此不可见,因此所有包含存档的portlet都需要包含在已部署的"app"的war文件中基于引擎的门户服务器".
"portlet"(至少在liferay中)作为永久servlet进程启动,基于它们的portlet.xmls和web.xmls,它们位于加载的每个portlet存档的相同位置.我想这可能是在应用程序引擎有问题的,因为一切都在一个大的"Web应用程序",因此它可能会非常棘手,从每个归档访问portlet.xmls.
这可以防止我认为100%的兼容性.
在这里有人对portlet和app引擎的组合有任何经验吗？
你认为修改jetspeed,pluto或任何其他portlet容器以便能够在app引擎上运行它是否可行？
有没有人有一个简明的摘要链接到什么使得portlet"JSR-286兼容"与仅仅"符合JSR-168".我有一个规范的副本,这是简洁的,所以链接规范不是一个有用的答案.我已经在网上搜索了一个小时,我发现没有什么是清楚的(除了规范,当然要求你也阅读以前的规范,然后从"必需"中删除"新功能"合规性".
特别是我发现在web.xml的必要性上存在相当多的混乱,这似乎来自使用Liferay的人并且没有意识到Liferay正在为他们放入web.xml.
JSR-286 portlet在WAR文件中是否需要web.xml文件？
我真正喜欢的是包含以下一个或多个列表的内容:
您可以在列表中留下"使用portlet-app_2_0.xsd",因为我认为这部分很明显.
我愿意接受这样的答案:除了portlet.xml的DTD/xsd之外,两个列表都是空的,区别仅在于门户网站支持的内容,但请用链接或其他引用来支持该断言.
我关心的原因是我在Liferay中看到关于Vaadin portlet的帖子暗示某些功能不适用于JSR-168 portlet ......也可能是Liferay中的某些逻辑根据它看到的portlet.xml版本切换,但我还没有证实这样做也是有趣的信息,但不是我的问题的答案.
我正在尝试使用jQuery/ajax调用portlet的serveResource()方法.我设法得到一个简单的JSR-286 portlet,它在Pluto 2.0中工作,能够从请求体读取JSON字符串,从JSON创建一个Java对象,并将该对象的toString()返回给我的调用JavaScript.但是,当我将相同的portlet部署到WebSphere Portal 6.1时,请求体在到达serveResource()时是空的.
我假设我遗漏了一些基本/基本的东西,所以任何建议都会受到赞赏.我认为如果我将JSON字符串推送到URL参数上,但我现在可以避免使用这种方法,我可以让我的示例工作,除非我给出了我当前方法"糟糕"的原因.
编辑:*更具体地说,我将相同的portlet部署到运行WSRP Producer的WAS7并通过WebSphere Portal 6.1使用portlet.
Javascript代码段:
function ajaxPost() {
var url = "<%= testServiceURL %>";
var current = $("input.current").val();
$.ajax(
{
url: url,
contentType: 'application/json; charset=utf-8',
dataType: 'html',
data: "{data: " + current + "}",
type: 'POST',
success: testSuccess,
error: testError
}
);
$("div.trace").append("ajax post fired<br />");
}
function testSuccess(data, textStatus, XMLHttpRequest)
{
$("div.trace").append("testSuccess(): " + data + "<br />");
}
Portlet代码段:
public class TestPortlet extends GenericPortlet {
...
@Override
public void serveResource(ResourceRequest request, ResourceResponse …我们正在讨论从liferay安装上的普通portlet开发切换到基于webmvc portlet的开发是否是一个好主意.
我们很快就会开始开发一些portlet,所以现在是时候了.但我看到的问题是我们想要使用一些portlet 2.0功能,这些功能不适用于早于spring 3.0的版本.(对？)
有没有人见过,如果值得等待？(什么时候预定3.0？)目前的里程碑是否足够稳定？
我们的第一个真正的发布将在今年的最后一个季度,所以springource的家伙还有一些时间来获得最后的决定...... ;-)
有任何想法吗？
UPDATE
因此,Spring 3已经发布,它支持我们需要的所有JSR286功能.(我认为这是对JSR286功能的完全支持)
我看到的唯一缺点是文档在注释方面没有达到速度.
我使用过Websphere Portal 6.0,6.1并开发了门户应用程序,使用JSR 168,JSR 286 Portlets.
现在我转到项目,我将使用Liferay门户服务器和JSR 168,JSR 286.
我知道根据编程接口(JSR)它将是相同的.但是想知道与Websphere Portal相比,服务器级别(功能,配置,架构,开箱即用服务)的主要区别是什么？
谢谢