我们都知道,在SharePoint中,Content page继承自Page layout,而Page layout又继承自Master page。Master page的作用大家都知道,它定义了站点的的整体外观和公共元素,因此有了很强的页面重用性和很好的页面编辑体验,Page layout通过ContentPlaceHolder为一些内容相似性很强的页面进行了布局,所以到了Content page那里,我们所做的只是放我们每个页面想要显示的内容即可,剩下的布局和样式都可以不用操心了。

 

好了,前面算是开场白吧!现在我们正式说重点,先从需求说起,客户要求整个站点的Footer部分要求从站点的List里面动态读取数据来生成它,而不是写死在master page里面,例如下面的图示,也就是说客户希望将来他们可以通过维护一个List数据来动态更新站点的Footer部分,附加排序,是否显示等功能,都有List里面的某个字段来控制,而不再需要有IT人员去更新了。

 

 

对于这个需求,我们可以有如下几种实现方式:

 

(一)  首先想到的是写一个Customized User Control,通过调用Object Model来呈现数据。部署完了dll以后,需要在Master Page里注册引用,然后才能去使用它,这里不再多说具体过程。这种方法好是好,但是不易维护,如果有任何逻辑改动,还需要重新部署dll到服务器端,很多时候不是很方便。

 

(二)  第二种方式是借助于Content Query Web Part,有人会说Master Page里面可以放Web part吗?动态的web part是不能加到Master page里的,因为Master page的内容是不允许从页面上修改的,但是我们可以放静态的web part,所谓静态的就是说web part不在web part zone里面。具体步骤如下:

1.  先建一个临时的测试页面,添加一个Content Query Web Part, 然后配置web part,如数据源,过滤条件及排序等属性。

2.  用SPD将次页面跟layout分离,然后打开它,找到相应的web part zone,我们发现zone里面是一个<PublishingWebControls:ContentByQueryWebPart>,其实它就是一个控件,将此控件拷贝出来放到Master page相应的html元素中即可,注意不要web part zone。

3.  更新List数据并刷新页面可以看到Footer是动态变化的了。注意:有时候换了环境可能会出现这个错误:There is a problem with the query that this Web Part is issuing. Check the configuration of this Web Part and try again. 这是因为ListGUID变了,所以必要的时候我们可以通过ListUrl和ListName属性来控制,而不再使用ListGUID。

 

(三)  第三种方式也是借助web part,只不过换成是Data View Web Part,所以跟第二种方式大体上应该差不多,就不再细说了。

 

以上几种方式,各有优缺点,相对来讲,第二种或第三种更容易维护,因为他们是OOB的,不涉及到服务器端代码,如果客户不让写服务器端代码,那么此时选择后者再合适不过了。也许还有其他更好的方式,有待探究。

作者: crazysharepoint 发表于 2010-11-30 21:33 原文链接

推荐.NET配套的通用数据层ORM框架:CYQ.Data 通用数据层框架
新浪微博粉丝精灵,刷粉丝、刷评论、刷转发、企业商家微博营销必备工具"