Re: Typo3 - Система управления сайтом
Rmr> Кто пользуется, пользовался системой управления сайтом Typo3 ваши отзывы
о ней
Rmr> безопастность, функциональность, стабильность ?
Блиииииин... Только не это........... Если у вас нет группы из 5-7
разработчиков, и лишнего месяца, чтобы понять систему, то лучше даже
не пытаться писать что-то более серьезное чем "интернет-магазин".
Конечно, сама по себе система - хороша. Куча документации (пусть
и написанной небрежным тоном), стандарты, внутренние проверки и т.д.
Море плагинов, продуманное API, само по себе open source - хорошо.
Но реализация, например, процесса привязки дизайна - чудовищна.
Вместо блочной структуры, понятной любому программисту и верстальщику
(страница есть блок, в который вложены другие блоки, в которые
вложены... и т.д.), используется чудовищный подход, наполовину
напоминающий ООП, а на вторую половину похожий на XSLT. Базовая
документация по системе предлагает верстать таким образом, словно
весь мир до сих пор раскрашивает тексты тегами FONT COLOR :-)
Несколько месяцев назад я проводил сравнительный анализ этой системы,
вот некоторые вырезки:
===cutИспользуется массив $GLOBALS. В современном стиле программирования
на PHP принято использовать $_SERVER.
Используется набор глобальных переменных (отдельно по именам),
например: global $BE_USER,$LANG,$BACK_PATH,$TCA;
На мой взгляд, использовать класс было бы правильнее:
global $someclass;
Очень огорчает прямой вывод HTML-кода из PHP:
$tableCode='<table border="0" cellpadding="1" cellspacing="1"
id="typo3-showitem">'.implode('',$tableRows).'</table>';
Хочется надеяться, что здесь разработчики просто допустили исключение
из правил, так как сейчас прямой вывод практически нигде не
применяется - используются различные шаблонизаторы.
По структуре данных:
На мой взгляд, сомнительная экономия в определении столбцов таблиц.
Например, uid ограничен длинной "11". Я уверен, что можно было без
проблем определить этот (и все аналогичные целочисленные) столбец как
bigint, или, если разработчики исходили из предположения что "так
много юзеров все равно никогда не будет", то ограничиться любой
меньшей длиной. То есть, число "11" выбрано по сомнительной причине,
на мой взгляд, следует выбирать либо минимальную длину (для хранения
числа 0 или 1), либо устанавливать максимальную длину (bigint) ВЕЗДЕ и
не иметь впоследствии проблем с нехваткой диапазона.
Значительно больший недостаток архитектуры БД - отсутствие явных
таблиц связи. Например, для пользователя группа задается
непосредственно в той же строке. Более правильный подход -
использование трех таблиц:
users: (id, name, ...)
groups: (id, name, ...)
users_groups_links: (id, user_id, group_id)
При таком подходе каждый юзер может принадлежать одновременно
нескольким группам.
Аналогичная ситуация и в таблице pages - хранить email автора (вместе
со всеми другими параметрами) было бы правильнее в таблице юзеров, а
из pages давать туда ссылку по идентификатору. Та же ситуация и в
таблице sys_note.
Странная логика в определении активности элемента:
инвертированное состояние - система вынуждает получать активные
(действующие) элементы путем запроса "WHERE deleted=0", когда было бы
проще и правильнее писать "WHERE active=1" :)
Кроме того, в системе реализован интересный SQL-драйвер: запросы не
хранятся в чистом виде с подстановочными параметрами, а "собираются"
взависимости от того, какой тип данных передается или запрашивается в
каждом конкретном случае. Эта идея мне знакома, но ее достоинства пока
не очевидны...
===cut--
Best regards,
dgstudio mailto:dgstud***@i*****.ru
библиотекa сайтостроительства http://www.i2r.ru/static/244/
