Saitistika 4.0.Руководство разработчика.2005

Подсистема поиска

Предназначен для поиска на сайте материалов, новостей, тем форумов, товаров и файлов, соответвтующих параметрам запроса.

Логика работы

Поиск реализован в одной хранимой процедуре (Sait_Search_List), которая производит отбор результатов согласно всем параметрам и фильтрам, в том числе и поиск файлов.

Особенности реализации фронтофиса

1.Логика «OR», «AND», «AND NOT»

2.Поиск в найденом

3.Сортировка результатов: по релевантности, по дате, по разделам, по типу контента

4.Релевантность

5.Построение ссылок в результатах поиска

6.Подсветка найденных слов. Найденные слова автоматически выделяются в тексте материала, если для вывода используется класс CMaterial. Для этого свойству CMaterial.Query нужно присвоить значение строки поиска. Внешний вид подсветки настраивается изменением класса marked в файле CSS.

Релевантность

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

Таблица весов релевантности

Таблица весов релевантности является жестко заданной и может быть изменена лишь в хранимой процедуре

Sait_Search_List.

При совпаении поикового слова с содержимым нескольких атрибутов, соответствующие коэффициенты складываются.

Например, если производится поиск по фразе «программное обеспечение» (без кавычек), то у материала со словом «программное» в названии и описании и словом «обеспечение» в описании и ключевых словах будет релевантность 100+33+88=221 (есть 3 атрибута, в которых нашлись слова, повторяемость не учитывается)

Фильтры

Для попадания в результаты поиска сущности должны быть доступны текущему пользователю по правам (если есть), а также удовлетворять критериям:

1.Общие для разных типов сущностей

1.1.Пометка «Не включать в индексирование поиском» не должна быть включена

1.2.У пользователя должны быть права на объект

2.Новость

2.1.Должна находиться в «зеленой» стадии

2.2.Должна быть опубликована хотя бы в одну из лент

3.Материал

3.1.Должен находиться в зеленой стадии

3.2.Должен быть опубликован хотя бы в один раздел

3.3.Должна быть хотя бы одна страница материала с непустым содержанием с пометкой «Активна»

3.4.Не должен быть устаревшим (период Expired)

4.Форум

4.1.Нет дополнительных фильтров

5.Товар

5.1.Должен иметь хотя бы одну разновидность

5.2.Должен быть включен хотя бы в один каталог магазина

6.Файл

6.1.Должен физически существовать

6.2.Должен находиться не в зеленой стадии

6.3.Должен не попадать в период Expired

Поиск файлов

Поиск файлов реализуется с помощью интеграции с Microsoft Indexing Service через Microsoft OLEDB Provider For Microsoft Indexing Service. Для поиска файлов используется связанный сервер (Linked Server), настроенный на каталог Indexing Service. Каталог Indexing Service, в свою очередь, настроен на индексацию требуемых директорий сайта. Кроме того, для физического файла может существовать запись в базе данных (в таблице Files). В этом случае при поиске учитываются права на файлы, статус материала и период Expired. Настройки индексирования и путей к каталогам сайта (локальных, виртуальных, сетевых), необходимые для работы поиска файлов, находятся в таблице FilesPaths и могут быть изменены на странице настроек поиска файлов в бэкофисе.

База данных

Хранимые процедуры

Sait_Search_List Search_GetFilterQuery

Классы

UML-диаграмма

Рисунок 21. UML-диаграмма классов модуля «Поиск»

Список классов

CSearchForm CSearchDecoration

Подсистема конфигурирования

Подсистема конфигурирования предназначена для настройки системы. Позволяет настраивать:

1.Общие установки системы

2.Типы данных

3.Атрибуты объектов

4.Статусы

Логика работы и особенности реализации

Общие установки системы

Общие установки системы – это глобальные настройки, влияющие на всю систему в целом. Конфигурационные настройки хранятся в таблице SystemSettings, считываются и используются некоторыми ASP-скриптами в процессе их работы.

Атрибуты объектов

1.Тип атрибута определяет способ хранения, отображения, область значений атрибута и механизмы работы с ним.

2.Система автоматически выполняет проверку корректности значений, присваиваемых атрибутам при работе с объектами. Например, при сохранении значения атрибута, имеющего тип «EMail», выполняется проверка корректности формата.

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

4.Для определения всех атрибутов предназначена таблица Fields. В этой таблице хранятся отображаемые названия атрибутов и признак активности.

Типы данных

1.Список всех типов и подтипов хранится в одной таблице, в таблице ObjectTypes. Различие между типом и подтипом заключается в том, что для подтипа поле TypeID содержит идентификатор типа, к которому относится выбранный подтип. А для типа это поле содержит значение null. Поля этой таблицы содержат названия объектных таблиц

2.При создании нового типа автоматически создаются следующие объектные таблицы:

2.1.Таблица объектов. Название совпадает с системным именем типа данных

2.2.Таблица, содержащая значения конструируемых атрибутов – оперативная. Название - <Тип данных>Storage

2.3.Таблица, содержащая значения конструируемых атрибутов – архивная. Название - <Тип данных>StorageArchive

2.4.Таблица, содержащая <Тип данных>Rights

3.Для связи типа данных с конструируемыми атрибутами предназначена таблица ObjectTypesFields

4.При отображении атрибутов объекта система выполняет следующие действия:

4.1.Определяется тип объекта, содержащийся в таблице объектов

4.2.По таблице ObjectTypesFields определяется набор атрибутов, которыми обладают объекты данного типа и свойства атрибута в составе объектов данного типа:

4.2.1.Значение по умолчанию

4.2.2.Обязательность

4.2.3.Порядок отображения на странице.

4.3.По таблице Fields определяются названия атрибутов. Названия отображаются.

4.4.Для атрибутов которые допускают выбор значений, из таблицы FieldVariants считываеются варианты выбора значений. Из вариантов формируются списки для отображения в виде ниспадающего меню, группы чекбоксов или группы радиокнопок.

4.5.Из таблиц <Тип данных>Storage или <Тип данных>StorageArchive считываются и отображаются значения

атрибутов

4.6.Отображаются только атрибуты, отмеченные как активные

5.Пользователь имеет возможность изменять тип объектов с одного подтипа на другой внутри этого же типа. При этом выполняются следующие действия с атрибутами объекта.

5.1.Если данный атрибут присутствует и у «старого» и у «нового» подтипа, его значение сохраняется.

5.2.Если данный атрибут присутствует у «старого» подтипа, но отсутствует у «нового», этот атрибут у всех существующих объектов отображаться не будет, но его содержимое останется в БД. Новые объекты, создаваемые после смены подтипа, будут создаваться без этого атрибута.

5.3.Если данный атрибут присутствует у «нового» подтипа, но отсутствует у «старого», этот атрибут добавляется во все существующие объекты и ему присваевается значение по умолчанию, определенное в «новом» подтипе.

6.При удалении подтипа указывается новый подтип, в который переходят все объекты удаляемого подтипа. Логика перехода аналогична описанной выше.

7.Системные атрибуты используются для функционирования самой системы. На страницах бэкофиса они отображаются красным цветом. Эти атрибуты в полном объеме можно использовать для создания новых объектов, но нельзя изменять их свойства.

8.При сохранении свойств подтипа выполняется проверка следующих условий корректности подтипа:

8.1.Подтип должен быть связан хотя бы с одним правильным сценарием

8.2.Подтип должен иметь хотя бы один включенный активный расширенный или конструируемый атрибут

8.3.Если проверяемый подтип связан с типом «Задачи», то он должен поддерживать все статусы всех связанных

сценариев

8.4.Если проверяемый подтип связан с типом «Проекты», то роли участников проекта должны покрывать список ролей для сценариев, связанных с данным подтипом

Статусы

1.Список статусов хранится в таблице Status.

2.В системе существуют системные статусы.

База данных

Общие установки системы

systemsettings – хранение общих установок системы

Типы данных, атрибуты, статусы Диаграмма таблиц

FieldVariants – возможные варианты выбора значений атрибутов. Используется для атрибутов, для которых значения

выбираются из списка предопределенных значений

Описание таблицы Workflows приведено в разделе, описывающем Подсистему Workflow

Хранимые процедуры

Простые. Описание не требуется.

Классы

Список классов

CDataType

Функции

settings-functions.asp datatypes-functions.asp

XSL-шаблоны

Подсистема Workflow

Подсистема workflow предназначена для настройки сценариев прохождения объектов системы между исполнителями

Логика работы

Особенности реализации

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

2.В узлах могут быть назначены роли. Пользователи, назначенные на роли, связанные с узлом, видят приходящие в узел задачи и могут передать их в другой узел.

3.Узлы связаны между собой связями. Для данной связи обязательно существует узел, исходящий и входящий узел.

4.Узел может быть связан с любым количеством соседних узлов.

5.Каждая связь сопоставлена с некоторым статусом и некоторой ролью. Присваивая задаче определенный статус при передаче, пользователь «отправляет» его по связи в следующий узел. Пользователь может «воспользоваться» связью только в том случае, если он назначен на роль, сопоставленную с этой связью. Причем несколько связей могут быть сопоставлены с одинаковым статусом. В этом случае при передаче задача попадет сразу в несколько узлов.

6.Процедура передачи задачи в текущем узле состоит в завершении текущей задачи, создании новой задачи и размещении

еев следующем узле. Логика, в соответствии с которой происходит передача значений атрибутов задач настраивается индивидуально для каждого узла.

7.При выходе из узла тип задачи может автоматически меняться. Тип задачи по умолчанию определен для связи.

8.Задания выполняются в рамках работы над проектом, соответственно, каждая задача связана с проектом. Проект имеет фиксированный список участников. Этот список нужен для назначения конкретных исполнителей задач по данному проекту в данном узле. Исполнители в узле – это пользователи из числа участников проекта, назначенные на ролисвязанные с данным узлом.

9.Сценарий, узел и связь можно сделать неактивными.

10.Можно использовать только правильно настроенные сценарии и связи. Критерии правильности: 10.1. Для сценариев:

10.1.1.Ровно один из активных узлов должен быть начальным

10.1.2.Хотя бы один активный узел должен быть конечным

10.1.3.Должен существовать хотя бы один маршрут по активным связям из любого узла в один из конечных

10.1.4.Во всех активных узлах должны быть назначены роли

10.2.Для связей:

10.2.1.На все активные связи должны быть назначены роли

База данных

Диаграмма таблиц

WorkflowLinks – предназначена для хранения информации о связях между узлами, принадлежащими определенному

сценарию

Классы

UML-диаграмма