Val Petruchek

подписывайтесь, а то хуже будет!  

ПОДПИСЫВАЙТЕСЬ НА RSS

Угадай, что прокомментировали

06.07.08 @ 10:41 — CMS

У меня в CMSине есть недоделка: в извещении о новом комментарии не указывается subject комментируемого материала, указывается только его URL.

Если в категории включены нечисловые урлы (вида /blog/scrabble-online.html), то никакой проблемы с идентификацией материала по урлу не возникает.

А если в категории используются числовые урлы (например: /blog/2008/06/25/167/), то очень часто не удаётся вспомнить, что же ты писал 25 июня 2008 года в блог.

В извещении приходит текст комментария целиком. Так вот, зачастую люди пишут такие комментарии (не спам!), по которым понять (не переходя по ссылке), какую заметку прокомментировал автор комментария не удаётся.

CMS: Textareas

19.04.08 @ 22:35 — Programming, CMS

Основным способом ввода информации в CMS через веб являются элементы управления типа <textarea>.

Для удобства пользователей и увеличения скорости ввода информации эти контролы часто заменяют на WYSIWYG-редакторы (What You See Is What You Get).

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

Разработчикам же для внедрения WYSIWYG-редактора требуется установить на сервер сам редактор, настроить его и вставить в шаблон пару javascript строк для замены плоской <textarea> на неплоское поле на клиенте.

При этом разработчики часто совершают ошибку: внедрив WYSIWYG в свою CMS, они не дают пользователю возможности не использовать этот WYSIWYG.

Речь не идёт о тех клиентах, которые не поддерживаются WYSIWYGом — в них контрол выглядит старой плоской <textarea>. А вот если у пользователя нормальный клиент, но при этом, например, интернет по GPRSу, то бедный этот пользователь: чтобы добавить контент ему понадобится достаточно много времени и денег (WYSIWYG подгружает достаточно много дополнительных файлов: javascript, css, images).

WYSIWYG надо внедрять так, чтобы у пользователя всегда была возможность не пользоваться им. Переключение между WYSIWYGом и plain <textarea> должно происходить без перегрузки страницы.

При этом plain <textarea> не должна быть действительно plain: к ней необходимо прикрутить quicktags для гиков.

Из всех WYSIWYGов наиболее удобным является TinyMCE.

CMS: отношения между сущностями

27.03.08 @ 15:32 — Programming, CMS

Рассмотрим некую предметную область, в которой имеются две сущности: category и object. Теперь рассмотрим два типа отношений, которые могут между ними существовать: один-ко-многим и многие-ко-многим.

Отношение один-ко-многим означает, что объект может принадлежать только к одной категории. В реляционной модели данных это отношение представлется добавлением поля category_id в таблицу объектов. При этом можно с лёгкостью:
1) узнать, к какой категории относится объект;
2) получить список объектов, принадлежащих категории.

Отношение многие-ко-многим означает, что объект может находиться в нескольких категориях. В реляционной модели данных это отношение отражается при помощи дополнительной таблицы отношений с полями object_id, category_id. Каждая запись в этой таблице содержит информацию о том “факте”, что объект с ID = object_id находится в категории с ID = category_id.

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

Если же в предметной области нет необходимости получать информацию о том, какие объекты содержатся в категории, то можно не создавать эту дополнительную таблицу. В этом случае всё, что нам надо получать от этого отношения: список категорий, к которым принадлежит объект. Для этого в таблице объектов можно создать дополнительное поле category_ids, содержащее список ID категорий.

Формат этого списка может быть любым: ID с разделителями, bitmask, внутренний формат какого-нибудь языка (например, serialized array для PHP). Критерий к формату этого дополнительного поля один: удобство использования в CMS.

Отказ от использования дополнительной таблицы в пользу дополнительного поля позволяет сократить количество запросов для получения информации об объекте. Платой за такой обмен является невозможнсть использования внешних ключей и потеря целостности данных (точнее, необходимость ручной поддержки целостности): целостность в обмен на быстродействие.

В идеале front-end CMS должен учитывать тот факт, что данные из этого дополнительного поля могут содержать ID категорий, уже несуществующих в системе, и обрабатывать их соответстенно.

Существует способ получить быстродействие без отказа от целостности данных: завести дополнительное поле не вместо дополнительной таблицы, а в дополнение к ней. Хранить в этом поле следует тоже самое — список ID категорий, к к которым принадлежит объект. В данном случае платой за быстродействие является приобретённая избыточность данных.

Чтобы эта избыточность не привела к противоречивости (когда в поле и в таблице хранятся несовпадающие ID категорий) необходимо поддерживать актуальность поля categoy_ids, которое в данном случае представляет из себя кэш данных из таблицы отношений.

  
Реклама::

 
Реклама::