最新评论
Re:（tip_修订0618）bmp 32位转24位 butterfly_sky 2010-03-30 14:29
O(∩_∩)O谢谢.........
re: 每个网站都应雇佣个人站长(ZT) 大力bober 2008-09-27 14:14
顶!
re: 每个网站都应雇佣个人站长(ZT) 小灰 2008-09-27 14:13
re: 想到的：wf和sharepoint 晴空 2008-09-26 10:06
学习中...sharepoint上面的工作流的扩展可能还要写些代码验证，
某种程度更希望sharepoint可以提供引擎，而不是现在这样的实现技术。
某种程度更希望sharepoint可以提供引擎，而不是现在这样的实现技术。
re: 想到的：wf和sharepoint jianyi 2008-09-24 21:17
不用自己找切入点了，SharePoint的工作流扩展就可以做很多工作。
re: sharepoint 扩展技术体会 Justin 2008-09-20 21:23
@晴空
是啊,现在.NET技术有如雨后春笋一样，想找一条适合自己的路真不是件容易的事情
是啊,现在.NET技术有如雨后春笋一样，想找一条适合自己的路真不是件容易的事情
re: sharepoint 扩展技术体会 晴空 2008-09-20 17:30
to justin
我也想做这方面的尝试，在看DotNetNuke
还在看一本书《asp。net3.5构建web2.0门户站点》
sharepoint的框架感觉抽象程度蛮高的，有了灵活性，由于工具的缺乏，就少了易用性和方向性，说实话，包括wf，和wcf都有类似问题，我感觉需要在这些技术上需要更大粒度的针对性的模块开发，才有可能达到快速、安全、稳定的系统。而且还有指向作用。
dot net框架，复杂性感觉已经超越java了，看看怎么在这么复杂的路线图中找出一条适合自己开发的路。
需要对这些技术进行裁剪，同样很复杂
我也想做这方面的尝试，在看DotNetNuke
还在看一本书《asp。net3.5构建web2.0门户站点》
sharepoint的框架感觉抽象程度蛮高的，有了灵活性，由于工具的缺乏，就少了易用性和方向性，说实话，包括wf，和wcf都有类似问题，我感觉需要在这些技术上需要更大粒度的针对性的模块开发，才有可能达到快速、安全、稳定的系统。而且还有指向作用。
dot net框架，复杂性感觉已经超越java了，看看怎么在这么复杂的路线图中找出一条适合自己开发的路。
需要对这些技术进行裁剪，同样很复杂
re: sharepoint 扩展技术体会 Justin 2008-09-16 19:58
问个问题：
脱离sharepoint，只用web parts Framework做portal开发会有多大难度，相比使用sharepoint做二次开发，好处有哪些？
脱离sharepoint，只用web parts Framework做portal开发会有多大难度，相比使用sharepoint做二次开发，好处有哪些？
re: sharepoint 扩展技术体会 雷君 2008-09-16 19:45
我们回头来看SHAREPONIT
从最初的英文介绍中的最经典的六大饼图来看.
门户是SHAREPOINT必须具备的一个功能,,,目前看来,.整合的以及门户的功能马马乎乎,虽然不能和BEA\ORACLE\IBM等产品相比,但是那毕竟不是同一级别的.
作为SHAREPOINT,我们应该定位为企业内容的管理,信息化支撑的一个体系平台,那么,简单的东西,我们可以定制,复杂的东西我们可以开发,我给别人培训的时候通常说SHAREPOINT应用就是70%配置+30%开发,那么配置的东西呢，有列表\栏\视图\内容等,同时也包括导航啊,权限啊,以及用SPEDITER等工具的定制,而开发呢,就是我们通常见到的EVENTHANDLER,部分WEBPART,以及一些SPD的定制的东西了..
做SHAREPOINT开发不难,也不容易,我们必须花一个月了解SHAREPOINT是什么,我们还必须一个月去了解SHAREPOINT整个体系是什么(别说太长,很多东西是需要经验需要时间去积累的).学习SHAREPOINT两年了,断断续续一直坚持着,在网上被很多人认为是所谓的高手,但是事实上,还是有很多东西不了解,那是因为我的.NET还没到家,,不过也正因为SHAREPOINT,让我恶补了很多.NET的基础.
另外WEBPART开发最好还是用USERCONTROL.用RENDER的方式确实太不美观了,,,那就真是把自己拉到解放前了.
从最初的英文介绍中的最经典的六大饼图来看.
门户是SHAREPOINT必须具备的一个功能,,,目前看来,.整合的以及门户的功能马马乎乎,虽然不能和BEA\ORACLE\IBM等产品相比,但是那毕竟不是同一级别的.
作为SHAREPOINT,我们应该定位为企业内容的管理,信息化支撑的一个体系平台,那么,简单的东西,我们可以定制,复杂的东西我们可以开发,我给别人培训的时候通常说SHAREPOINT应用就是70%配置+30%开发,那么配置的东西呢，有列表\栏\视图\内容等,同时也包括导航啊,权限啊,以及用SPEDITER等工具的定制,而开发呢,就是我们通常见到的EVENTHANDLER,部分WEBPART,以及一些SPD的定制的东西了..
做SHAREPOINT开发不难,也不容易,我们必须花一个月了解SHAREPOINT是什么,我们还必须一个月去了解SHAREPOINT整个体系是什么(别说太长,很多东西是需要经验需要时间去积累的).学习SHAREPOINT两年了,断断续续一直坚持着,在网上被很多人认为是所谓的高手,但是事实上,还是有很多东西不了解,那是因为我的.NET还没到家,,不过也正因为SHAREPOINT,让我恶补了很多.NET的基础.
另外WEBPART开发最好还是用USERCONTROL.用RENDER的方式确实太不美观了,,,那就真是把自己拉到解放前了.
re: sharepoint 扩展技术体会 晴空 2008-08-30 12:29
to 雷君
感谢您的意见。
兄弟我的思路和老兄你的很接近，我最近在公司的会上说，sharepoint最适合做的是知识管理，项目小组内部协同系统，和文档共享系统。
另外就是利用portal的能力，作为整合和共享平台，不过要做的工作尤其一些基础的开发量还是比较大的。
我的思路是要有一个web servies做异构平台的交互。
一个工作流引擎做业务流转的支撑。先打住，这要扯起来不知道要写多少字啦，哈哈。
Event问题是我探索不够，经过两天的摸索，布置完毕，我正打算写出来。
还有rss 或者atom我打算过一阵深入学习一下，如果用webpart render这种方法作为门户感觉太沉重了。
web的开发我还在学习中，毕竟今年3月前我还是用delphi做桌面应用的
感谢您的意见。
兄弟我的思路和老兄你的很接近，我最近在公司的会上说，sharepoint最适合做的是知识管理，项目小组内部协同系统，和文档共享系统。
另外就是利用portal的能力，作为整合和共享平台，不过要做的工作尤其一些基础的开发量还是比较大的。
我的思路是要有一个web servies做异构平台的交互。
一个工作流引擎做业务流转的支撑。先打住，这要扯起来不知道要写多少字啦，哈哈。
Event问题是我探索不够，经过两天的摸索，布置完毕，我正打算写出来。
还有rss 或者atom我打算过一阵深入学习一下，如果用webpart render这种方法作为门户感觉太沉重了。
web的开发我还在学习中，毕竟今年3月前我还是用delphi做桌面应用的
re: sharepoint 扩展技术体会 雷君 2008-08-29 19:44
sharepoint定位为一个协作和共享平台,并不是特别适合做逻辑非常复杂的应用,例如有网友喜欢问SHAREPOINT如何来做工作流,我觉得这些复杂的应用就应该用另外的方式去做,例如购买相应的工作六产品,或者用VS开发WWF工作流.毕竟SHAREPOINT只提供了简单的工作流...这些高级的应用事实上还不够完美,我们可以尝试,然后期待2009的出现吧
re: sharepoint 扩展技术体会 雷君 2008-08-29 19:43
补充楼主所说的...sharepoint有一些特点
everything have rss
everything have object model
everything is feture
everything have rss
everything have object model
everything is feture
re: sharepoint 扩展技术体会 雷君 2008-08-29 19:42
linq to sharepoint 我还没试.我觉得有必要试一下..
目前我们的应用越来越多,我越来越感到性能方面的问题了
目前我们的应用越来越多,我越来越感到性能方面的问题了
re: sharepoint 扩展技术体会 雷君 2008-08-29 19:41
我经常用EVENTHANDLER来做辅助,没有发现你说的错误的问题啊
基本上我的思想和楼主的比较类似.
经过两年的研究,最近这几个月一直在用这个来做一些应用的开发,如果说在管理信息系统方面,特别是日常的信息管理方面, 那么会比较有优势...
有机会可以一起聊聊体会。
基本上我的思想和楼主的比较类似.
经过两年的研究,最近这几个月一直在用这个来做一些应用的开发,如果说在管理信息系统方面,特别是日常的信息管理方面, 那么会比较有优势...
有机会可以一起聊聊体会。