|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-30
openeyes 写道 wyuch 写道 [另一个重要问题是用户认证，其实使用iframe实现统一的用户认证也不是不可以的，但根据常见的SSO机制（以CAS为例），每个业务系统都集成到CAS中，那么各个iframe里的URL被访问时将会自动重定向到CAS服务器以获取LoginTicket，整个过程不需要程序员控制，即可实现统一认证。但这样的缺点是用户感觉不太友好，页面跳转次数太多了。
如果有能力修改SSO实现，那么在使用iframe的情况下可以由Portal代为申请LoginTicket或者别的什么Ticket，将其作为参数附加到iframe的src属性对应的URL上，这样跳转次数较少。但依然不是特别理想，如果页面iframe较多，用户体验还是不理想。 如果是以Protal作为HttpClient的形式代理用户向其他业务系统访问JSP页面，那么就可以使用CAS中的代理模式（或者类似），直接产生ProxyTicket向其他业务系统请求页面即可。对于用户来说，他只下载了一次HTML，用户体验比iframe要好。 我们知道这种代理访问本身需要的系统资源是很少的，真正的运算在业务系统上，性能上的问题不大，如果SSO和Portal是合二为一或者是同一个容器内的，那么性能就更不成问题了。 你说通过CAS获取LoginTicket,那么获取的凭证怎么带过去？是在url中加一个参数吗？ 如果这样的话，portlet页面中的链接(例如有一个最新邮件的列表的portlet,你选中某个邮件点击链接会弹出一个详细内容的页面,这个页面实际上是OA系统的范围了），那么这些链接是否都要加获取LoginTicket的参数呢？ 只需在第一次展现iframe中的内容时通过URL带去LoginTicket（即<iframe src="URL">中的URL部分），这时业务系统已经鉴别过这个LoginTicket并为用户建立起Session了，以后的访问（比如你点击某个邮件）就不需要再带LoginTicket了呀。 不过iframe始终不是个好的方案。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
最后修改：2009-07-30
CoxZhang 写道 恩，是否可以这样，自己做的portlet只负责呈现数据和传递业务参数，然后实际的业务处理交给业务处理的portlet或servlet？例如，前面的薪水portlet，除了外观参数外，可以让用户减薪水（模拟转账）， 然后由一个负责处理用户薪水的portlet或servlet处理。让业务处理的portlet或SERVLET跟表现的PORTLET分离。
当然，这还要涉及用户验证等等。 不成熟的想法，请各位先进指正 我的想法大体和你一致。不过我想不需要为每一个业务系统的JSP页面都建立一个对应的符合JSR168的Portlet，因为这些Portlet实际上不起作用，只是一个中间代理的角色，所以我想在JSR168的基础上额外支持这种需求，通过在Portal里进行简单配置即可直接使用业务系统上的JSP（当然是组织得比较良好的，起码不能带<html>标签，只能是一个片段）,其他的界面样式、布局、拖拽、用户认证都由Portal来自动管理。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
我当时也研究过portal一段时间，
我觉得portal技术思想很好，但是要实际实现N复杂！！！英文和中文文档也少的可怜。 另外，我当时研究的就是Jetspeed2，我只能说这个东西 还很不完善，很原始。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
wyuch 写道 高手快谈谈看法。上传同事做的一个Portal的界面原型，可以换肤，还是很漂亮的。
 这个是portl页面吗？这个明明是个html页面。。。。。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
foxxiao 写道 wyuch 写道 高手快谈谈看法。上传同事做的一个Portal的界面原型，可以换肤，还是很漂亮的。
这个是portl页面吗？这个明明是个html页面。。。。。 大哥，我说了我还没有开始做呀，这只是个界面原型 |
| 返回顶楼 | |
|
发表时间：2009-07-30
最后修改：2009-07-30
你所说的伪portal，在session的解决上 会是个 很大的问题！！
另外，还有一些权限认证的东西 ，这个可能 需要自己在重新定义 |
| 返回顶楼 | |
|
发表时间：2009-07-30
前面有很多人在讨论iframe做portlet。那的确是最土最低层次的实现方式，看起来简单，如果整个portal都是iframe，可以想象那是多么痛苦的事情。首先，IE对iframe有bug，加载页面时iframe太多页面就会假死。然后，整个门户页面就是一个个洞一个个滚动条。然后，皮肤样式这些，在iframe中都无法控制了。然后，布局无法细化了。然后，如果iframe所在服务器挂了就是一个个错误框。
portlet业务方面，portlet要跟portal交互的只有用户登录信息（也就是个用户ID），通过jaas可以把登录信息传到portlet上。至于portlet实现的业务，那是各个portlet自己控制的，跟portal可以没有一毛钱关系。 portlet兼容性方面，只要你严格按照JSR168规范来做，不针对Portal产品扩展，几乎不会有对Portal兼容性问题。portle真正兼容性问题在于各个厂商对servlet的实现各有不同引起的问题，如portlet对taglib的解析在各服务器上不一样，同样jstl、jsf这些都有问题。 所以，我总结了portlet用Velocity/Freemarker做页面是最好的，别用什么jsp、jstl、jsf等跟servlet打交道的东西。 Portal是一个很实用的产品，实施的时候立竿见影，客户马上可以看到效果，所以很多公司都开始搞了。大家努力吧。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
lnaigg 写道 前面有很多人在讨论iframe做portlet。那的确是最土最低层次的实现方式，看起来简单，如果整个portal都是iframe，可以想象那是多么痛苦的事情。首先，IE对iframe有bug，加载页面时iframe太多页面就会假死。然后，整个门户页面就是一个个洞一个个滚动条。然后，皮肤样式这些，在iframe中都无法控制了。然后，布局无法细化了。然后，如果iframe所在服务器挂了就是一个个错误框。
portlet业务方面，portlet要跟portal交互的只有用户登录信息（也就是个用户ID），通过jaas可以把登录信息传到portlet上。至于portlet实现的业务，那是各个portlet自己控制的，跟portal可以没有一毛钱关系。 portlet兼容性方面，只要你严格按照JSR168规范来做，不针对Portal产品扩展，几乎不会有对Portal兼容性问题。portle真正兼容性问题在于各个厂商对servlet的实现各有不同引起的问题，如portlet对taglib的解析在各服务器上不一样，同样jstl、jsf这些都有问题。 所以，我总结了portlet用Velocity/Freemarker做页面是最好的，别用什么jsp、jstl、jsf等跟servlet打交道的东西。 Portal是一个很实用的产品，实施的时候立竿见影，客户马上可以看到效果，所以很多公司都开始搞了。大家努力吧。 我承认iframe不好，但目前还没有找到更好的方式。举个例子，我portal用的是jetspeed,context path是 /jetspeed, 然后我有个应用是oa, context path是/oa, 在portal中我有个portlet是最新邮件列表，这个 portlet是在oa这个web app中的, 所有我在portal页面上要点击查看某个邮件详细信息的话，链接是/oa/email/email?id=198, 这个时候就会出现oa的登录框，这个怎么解决？ 谢谢 |
| 返回顶楼 | |
|
发表时间：2009-07-30
openeyes 写道 我承认iframe不好，但目前还没有找到更好的方式。举个例子，我portal用的是jetspeed,context path是 /jetspeed, 然后我有个应用是oa, context path是/oa, 在portal中我有个portlet是最新邮件列表，这个 portlet是在oa这个web app中的, 所有我在portal页面上要点击查看某个邮件详细信息的话，链接是/oa/email/email?id=198, 这个时候就会出现oa的登录框，这个怎么解决？ 谢谢 我上边已经说了这个问题的，如果引入了SSO，你点/oa/email/email?id=198直接就进入了OA的相应页面，不会出现登录框的。建议你装个CAS试试，了解一下它的机制。 在iframe下： wyuch 写道 只需在第一次展现iframe中的内容时通过URL带去LoginTicket（即<iframe src="URL">中的URL部分），这时业务系统已经鉴别过这个LoginTicket并为用户建立起Session了，以后的访问（比如你点击某个邮件）就不需要再带LoginTicket了呀。 在代理访问的情况下： wyuch 写道 如果是以Protal作为HttpClient的形式代理用户向其他业务系统访问JSP页面，那么就可以使用CAS中的代理模式（或者类似），直接产生 ProxyTicket向其他业务系统请求页面即可。对于用户来说，他只下载了一次HTML，用户体验比iframe要好。 |
| 返回顶楼 | |
|
发表时间：2009-07-30
foxxiao 写道 你所说的伪portal，在session的解决上 会是个 很大的问题！！
另外，还有一些权限认证的东西 ，这个可能 需要自己在重新定义 应该不会是一个很大的问题，用apache的httpclient就可以。用户在某个伪Portlet上验证通过后的响应中会包含Cookie（我们不妨假定所有会话都基于Cookie），该Cookie中会有SessionID，则Portal后续的对此伪Portlet的所有请求，都只需将包含SessionID的Cookie带回去，即可实现用户到某个伪Portlet的Session。原理和普通的Session没有区别，只是普通Session由浏览器自动发送Cookie，而Portal代理访问伪Portlet时需要写程序手工管理Cookie的回发，还需要建立Cookie与用户的关联。 |
| 返回顶楼 | |
