WebParts для SharePoint-Девелопмент - PullRequest
1 голос
/ 02 февраля 2011

Мне известны только два подхода, которые мы можем разработать для веб-частей с помощью Visual studio.

Первый :

Добавьте проект веб-части и напишите код соответствующими методами.

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()

Развертывание решения напрямую с VS. Возьмите файл WSP и используйте STSADM.EXE для развертывания на сайте / ферме. Это стандартный подход, которому нужно следовать.

Второй подход:

Создайте пользовательский элемент управления и скопируйте Usercontrol.ascx и Usercontrol.ascx.cs в _Layouts.

Создайте новый проект веб-части и зарегистрируйте элемент управления, используя

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

И разверните его из VS.

Но этот подход не выглядит безопасным, поскольку мы вручную копируем в _layouts.

Единственная причина, по которой мы собираемся использовать этот подход, заключается в том, что мы можем отображать элементы управления так, как нам хочется, и не беспокоиться о том, чтобы видеть различные события жизненного цикла веб-части.

Может кто-нибудь сообщить мне, какой подход вы используете в вашей компании.

Спасибо.

Хари Гиллала

Ответы [ 3 ]

1 голос
/ 07 февраля 2011

Когда я начал разрабатывать в SharePoint 2007, мы использовали первый метод, который вы описали.Через некоторое время мы переключились на что-то вроде второго метода.

Однако вместо того, чтобы помещать файлы ascx в макеты, мы помещаем их в пользовательский каталог под controltemplates.Код нашей веб-части затем выглядел так:

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

Если бы у нашей веб-части были какие-либо дополнительные свойства или части инструментов, они были бы обработаны в этом классе и затем перенаправлены в класс управления.Мне очень понравилось отделение логики управления от логики веб-части.Кроме того, мне понравилось иметь возможность управлять макетом элемента управления в HTML или использовать дизайнер Visual Studio.

И эти файлы не нужно развертывать вручную.Затем может быть включен в ваш пакет решений.Точно так же, как у вас есть путь для развертывания ваших функций в каталоге 12 \ TEMPLATE \ FEATURES, вы можете развернуть файлы ascx в 12 \ TEMPLATE \ CONTROLTEMPLATES.

0 голосов
/ 02 февраля 2011

sp2007, в любом случае все было в порядке, это зависит только от того, как вам нравится строить дерево управления. я предпочитаю первый метод.

sp2010 у вас есть еще несколько вариантов.

1) Ваш первый выбор - веб-часть в песочнице, в которой используется подход построения кода.

2) Если это слишком ограничено, вы можете попробовать визуальную веб-часть, аналогичную интеллектуальной части из sp2007.

3) И тогда есть стандартный подход, основанный на коде.

0 голосов
/ 02 февраля 2011

Определенно второй, просто посмотрите на визуальные веб-части в 2010 году (они построены именно так).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...