开发者

sharepoint-Webparts-Development

开发者 https://www.devze.com 2023-02-08 06:29 出处:网络
I am only aware of two approaches we can develop webparts using Visual studio. The First one: Add a webpart project and write code in the appropriate methods.

I am only aware of two approaches we can develop webparts using Visual studio.

The First one:

Add a webpart project and write code in the appropriate methods.

protected override void OnInit(EventArgs e)
protected override void OnLoad(EventArgs e)
protected override void CreateChildControls()
protected override void LoadViewState(object savedState) //Only at Postback
protected override void OnPreRender(EventArgs e)
protected override void Render(System.Web.UI.HtmlTextWriter writer)
protected override void OnUnload(EventArgs e)
public override void Dispose()

Deploy the Solution directly from the VS. Take the WSP File and use STSADM.EXE to deploy across the Site/Farm.This is the standard approach to follow.

开发者_如何学JAVASecond approach:

Create a User Control and copy the Usercontrol.ascx and Usercontrol.ascx.cs to _Layouts.

Create a new webpart project and register the control using the

_UserControl = this.Page.LoadControl("\\_layouts\\_UserControl.ascx");

And Deploy it from the VS.

But this approach is not looking safe as we are manually copying to the _layouts.

The only reason we are going to take this approach is we can display the controls the way we want and not bothered to see the various events of webpart life cycle.

Could anybody let me know what approach you are taking in your company.

Thank you.

Hari Gillala


When I started developing in SharePoint 2007, we used the first method you describe. After some time, we switched to something like the second method.

However, instead of placing the ascx files into layouts, we put them in a custom directory under controltemplates. Our web part code then looked like this:

public class OurControlWebPart : WebPart 
{
    protected override void CreateChildControls()
    {
        base.CreateChildControls();
        Control userControl = 
            Page.LoadControl("~/_controltemplates/OurProject/OurControl.ascx");
        Controls.Add(userControl);
    }
}

If our web part had any additional properties or toolparts, they would be handled in this class and then forwarded onto the control class. I really liked the separation of the logic of the control from the logic of the web part. Also, I liked being able to control the layout of the control in HTML or using the Visual Studio designer.

And these files do not need to be deployed manually. Then can be included in your solution package. Just like you have a path deploying your features to the 12\TEMPLATE\FEATURES directory, you can deploy your ascx files to 12\TEMPLATE\CONTROLTEMPLATES.


Definitely the second one, just look at the visual webparts in 2010 (they are built exactly like that).


sp2007, either way was fine, it just depends on how you like building your control tree. i prefer the first method.

sp2010 you have a few more options.

1) Your first choice should be a sand boxed web part, which uses a code building approach.

2) If that is too limited, you can try a visual web part, similar to the smart part from sp2007.

3) And then there is the standard code based approach.

0

精彩评论

暂无评论...
验证码 换一张
取 消