воскресенье, 24 марта 2013 г.

Scrum и Definition of Done

Во время работы в костромском Softline, мы не раз и не два сталкивались с проблемой неверно/неточно сформулированных задач. Нередко это приводило к многократным перепинываниям задач туда-сюда - что в свою очередь выливалось в конфликты и споры между разработчиками и тестировщиками. Это все было неприятно и значительно снижало продуктивность нашей команды.

В этом посте я хочу описать, как мы пытались решить эту проблему в Softline, и про мой опыт работы в Scrum-команде в Финляндии, где эта проблема была решена с помощью Definition of Done.

понедельник, 11 марта 2013 г.

Wait/loading диалоги в SharePoint

Пара недокументированных стандартных диалогов. Сделаны по тому же принципу, что я описывал для Confirmation-диалогов, но уже входят в состав SharePoint - что приятно :) Возможно, пригодятся.

Буду краток:


Этот диалог выводится следующим куском JS:

var dialog = SP.UI.ModalDialog.showWaitScreenWithNoClose("test", "test message", 190, 350)
// делаем что-нибудь асинхронное и долгое
// по завершении, вызываем
dialog.close(SP.UI.DialogResult.OK);

Можно использовать для каких-нибудь долгих асинхронных операций.

Если вы хотите дать пользователю возможность отменить вашу операцию (что желательно), используйте другой метод:

var dialog = SP.UI.ModalDialog.showWaitScreenSize("test", "test message", function (dialogResult) { alert(dialogResult); }, 150, 350);

Вы автоматически получите кнопку "Отмена" и при ее нажатии, сработает callback (dialogResult будет равен 0, т.е. SP.UI.DialogResult.cancel).


К слову, в клиентской объектной модели и SP.UI в SharePoint 2013 добавилось очень много всего недокументированного (те же callback'и чего стоят, или SP.Taxonomy). Надеюсь, задокументируют позже - все-таки лазать в сгенерированных Script#-ом исходных кодах SharePoint JavaScript API, где все локальные переменные заобфусцированы - то еще удовольствие :(

четверг, 7 марта 2013 г.

Динамическая форма списка в SharePoint Designer

Как известно, SharePoint Designer (далее SPD) генерит формы списков в “статическом” виде (Lists and libraries –> [ваш список] –> Forms –> New…). На каждое поле списка в XSLT разметке генерится отдельный тэг <tr>, в который захардкожены значения для заголовка и названия поля. Выглядит один такой <tr> следующим образом:
<tr>
    <td width="190px" valign="top" class="ms-formlabel">
        <H3 class="ms-standardheader">
            <nobr>Title<span class="ms-formvalidation"> *</span>
            </nobr>
        </H3>
    </td>
    <td width="400px" valign="top" class="ms-formbody">
        <SharePoint:FormField runat="server" id="FormField1" ControlMode="Edit" FieldName="Title" __designer:bind="{ddwrt:DataBind('u',concat('ff1',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Title')}"/>
        <SharePoint:FieldDescription runat="server" id="FieldDescription1" FieldName="Title" ControlMode="Edit"/>
    </td>
</tr>

Таких кусков в XSLT коде столько, сколько у вас на форме полей.

Этот подход приводит к очевидным неприятностям: если в список добавилось новое поле, форму придется перегенерить. Что неприятно: списки они ж ведь на то и списки, чтобы пользователи сами туда могли добавлять поля!…

Оказывается, решить эту проблему – очень легко.

среда, 6 марта 2013 г.

Способы кастомизации форм списков в SharePoint 2013

Я уже писал про формы списков и про то, как их можно кастомизировать, однако в свете новых возможностей SharePoint 2013, а также накопившегося с того времени опыта (прошло уже 1.5 года, как время летит!), хочется еще раз пробежаться по этой теме.