Шаблоны и движок: проблемы версий

В прошлом посте я упомянул о проблеме совместимости шаблонов разных версий скрипта. Имеется в виду ситуация, когда пользователь скрипта v1.0 изменил шаблоны, но появляется версия 1.5, где ряд шаблонов изменен (возможно существенно). И ему приходится вручную все переделывать, сравнивая разные версии шаблонов.

Итак я пришел к следующим выводам.
1. Не зашивать дизайн жестко в код скрипта.
2. Не использовать XSL/XSLT, т.к. юзер наверняка не умеет с этим работать.
3. Использовать Smarty в качестве шаблонизатора.
4. Максимально загрузить CSS при верстке дизайна, как например на Хабре.

Такой расклад меня полностью устраивает. Надеюсь, что пользователей тоже.

Атрибуты нормального скрипта для продажи.

Что я думаю о том, какие возможности должен предоставлять коммерческий скрипт/движок.

1. Удобный установщик.
- скачиваем архив скрипта, распаковываем и заливаем папку на сервак;
- залезаем через браузер на будущий сайт (или что там будет), где тут же выскакивает конфигуратор/установщик;
- указываем данные по доступу к БД плюс некий минимум для работы, жмем "Next"
- автоматом создаются все необходимые таблицы в БД, проверяются зависимости библиотек, доступность каталогов для записи и пр. В случае неудачи показывается описание ошибок и кнопка "Retry";
- итак, финальное окно, возможно, с просьбой удалить какие-нибудь файлы установщика.

2. Все настройки скрипта производятся только на сайте, т.е. не надо лезть в текстовые конфиги и править параметры там руками. Хотя сами настройки в таком файле и хранятся. :)

3. Отделение кода обработки данных от представления данных, т.е. дизайн хранить в шаблонах, и использовать, например, smarty для отображения.

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

Вот тут есть неприятный момент, когда пользователь изменит шаблон под себя (я сторонник предоствления ему полного контроля отображения), а в новой версии скрипта какие-нибудь шаблоны будут изменены... И что после этого полноценную CMS делать?

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

5. Поддержка скрипта.
- написание мануалов по установке и использованию;
- отслеживание возможных багов, да и просто на вопросы юзверей отвечать.

...

Eclipse + Subversion. Начало.

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

Остановился на Subversion, не знаю даже почему, т.к. в этом деле новичок. Доку по ней можно почитать тут: http://svnbook.red-bean.com. Все установки производил на компе под управлением Windows XP SP2.

Бинарники Subversion под винду берем здесь. Мне попался svn-1.4.3-setup.exe, который я поставил в c:\Subversion. В процессе установки отказался от пункта модификации конфига апача.

Если брать zip-архив, то придется создать переменную окружения APR_ICONV_PATH = c:\subversion\iconv, и в PATH добавить путь c:\subversion\bin.

Настраиваем Apache. В httpd.conf включим модули DAV, добавим 2 модуля SVN и прописываем Location с указанием хранилища репозиториев:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_svn_module "C:/Subversion/bin/mod_dav_svn.so"
LoadModule authz_svn_module "C:/Subversion/bin/mod_authz_svn.so"
...
<Location /svn>
DAV svn
SVNParentPath d:\repos
</Location>

Создание репозитория делается с помощью команды
svnadmin create --fs-type fsfs testproject
(вместо fsfs можно bdb), текущим каталогом при этом должен быть SVNParentPath, т.е. d:\repos.

Теперь добавим поддержку SVN в Eclipse. Для этого используем плагин subclipse. Там все расписано и установка не займет проблем. В случае отсутствия инета можно использовать zipped-версию, скачанную на другом компе. Я брал site-1.2.0.zip и устанавливал как "New archived Site".

В eclipse появится перспектива SVN Repository Exploring, и там указываем наш тестовый репозиторий проекта: http://localhost/svn/testproject. Через "New remote folder" в контекстном меню создаем нужные папки/ветки разработки:
trunk - текущая (основная) разработка,
tags - тут будут папки с релизами,
branches - а тут будут временные ветки будущих версий (они потом сольются в trunk).

Чтобы поместить существующий проект Eclipse в SVN используем контекстное меню "Team - Share project" в окне, скажем, "Navigator". Выбираем тип репозитория SVN. В качестве Repository Location указываем существующее http://localhost/svn/testproject, потом имя/папку проекта, небольшой коммент по импорту, жмем Finish и выбираем файлы для commit.

Управление SVN ведется через контекстное меню Team. Основные команды - update и commit. Но об этом в другой раз.

Why?

Зачем открыл блог? Вообще говоря, планирую его использовать как интернет-блокнот. Чтобы не держать в голове описания некоторых не часто встречающихся операций и прочей ерунды, и иметь к ним доступ из любого места: домашнего или рабочего компов, ноутбука, кпк и бог знает откуда еще.

Еще думаю, что эти записи могут кому-нибудь пригодиться. И дабы сильно не заморачиваться с синхронизацией всех этих девайсов и было принято решение о создании блога.

Почему на Blogger? Да потому что я постоянно залогинен у гугла: Google Reader, GMail, etc. И мне удобно иметь один аккаунт на все. Ну и пусть "большой брат все видит"... :) Тем более, что немного поигравшись с livejournal.com мне показалось, что медленноват он, местами черезчур.

Собственно пока все.