Перенаправление на главную страницу (Master page, SharePoint 2010)

- Задание -

При использовании действия "Войти под другим пользователем" новый пользователь должен быть перенаправлен на главную странцу (рис. 1), а не на ту, с которой было выполнено действие.

Рис. 1. Необходимая кнопка для изменения.

Группа ссылок на пользовательской странице. (CustomActionGroup на LayoutsPageBase).

Статья написана в продолжение предыдущей. Советую сперва её прочитать, чтобы сложилось полная картина о всем написанном в данной статье.

Итак, предположим, что вы создаете решение для SharePoint 2010, часть которого представляет собой пользовательскую группу (CustomActionGroup) с ссылками на соответсвующие страницы (CustomAction). Предположим, что вы хотите отобразить эту группу ни в одной из расположений по-умолчанию, а вообще на отдельной странице (на разработанной вами!). Всё намного проще, чем предполагалось и не надо всё самому рисовать, разбирать xml...

Понеслась. Я буду использовать наработки из предыдущей статьи. Конечный результат можно посмотреть на рис. 1.

Рис. 1. Конечный результат.

Пользовательская ссылка и Central Administration (SharePoint 2010)

Мда, запустил я свой блог.

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

На данный момент работаю над проектом под SharePoint Server 2010 и вчера возникла необходимость добавить custom link на панель быстрого запуска в Central Administration (далее, CA). Сперва поискал ("погуглил") на эту тему в интрнете, ничего внятного не нашел. Некоторые разработчики говорили, что это возможно, но сложно, а некоторые - невозможно вообще.

Теперь я вам докажу, что это возоможно! :)

Table-per-Type (EntityFramework)

Сегодня будем рассматривать иерархическую структуру данных для ORM Entity Framework. Сразу хочу оговориться, что ORM относительно молодая по сравнению с nHibernate, но уже успела впечатлить меня тем, что для неё есть встроенный редактор! :)

Итак, сразу к делу. Есть 3 вида компаний: Клиент (Client), Производитель (Manufacturer) и Подрядчик (Contractor). Структура базы будет следующей (Данные об этих сущностях будут сразу сведены к минимуму):

Рис. 1. Упрощенная структура базы данных.

Table-per-Type (ActiveRecord)

Работая над последним проектом, возникла проблема разделения абстрактных и конкретных сущностей. Вырву кусок ТЗ из контекста: необходимо была возможность легкой расширяемости служб инкассации. Например, существует на данный момент 3 вида инкассации: инкассация Сбербанка, внутренняя и фельдьегерская (вроде бы, инкассация НБУ, во всяком случае государственная) инкассации. Задача была в безболезненном добавлении новых служб.

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