воскресенье, 20 декабря 2009 г.

Конфигурация системы. Класс работы с настройками.

Любая система работает с некоторыми настройками. Если Ваша система не имеет параметров — она деревянная.
  • Ядру CMS нужны настройки;
  • Настройки нужно где-то хранить;
  • Настройки должны иметь удобочитаемый формат для правки, в экстренных случаях, руками;
  • Кроме ядра, параметры могут иметь и каждый модуль CMS;
  • Каждый имеющий параметры модуль, не должен заботиться о том, в каком виде хранятся параметры и где они хранятся;
  • Ядро должно предоставлять строго определенный интерфейс для работы с параметрами любого модуля и отдельно — работу со своими параметрами (на случай модуля настройки ядра).

Спасибо, КЭП.

Основные моменты ясны. Теперь нужно обсудить решение.

суббота, 19 декабря 2009 г.

Структура папок CMS. [Внеплановая заметка]

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

суббота, 12 декабря 2009 г.

Создание сайта

При создании сайта, закладывается некий смысл. Т.е. кроме тематики определяется структура сайта, его основной функционал.

Возможно, я что-то пропущу, но перечислив основные типы сайтов, Вы сможете понять о чем я.

  1. Визитка компании

    Сайт наполненный фирменным стилем компании или бренда. Сайт содержит общую информацию о компании или продукции. Много текста и минимум функционала для пользователя сайта.
  2. Каталог товаров

    Почти не суть важно откуда берутся (в системе) товары. Важно, что 2/3 навигации происходит именно по каталогу позиций.
  3. Специфические проекты

    Тут уже кто во что горазд.

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

пятница, 11 декабря 2009 г.

Ядро CMS. Поддержка языков в системе. Часть 2.

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

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

пятница, 13 ноября 2009 г.

Поддержка языков в системе. Часть 1.

Система Управления Контентом, в любом случае должна поддерживать работу в режиме -- множество языковых версий сайта.
Описываемая мной система также должна поддерживать работу нескольких локализаций.
Не так давно, на форуме русского сообщества CodeIgniter обсуждалось, Как организовать поддержку нескольких языков на сайте? Там этот вопрос рассматривался в контексте одного веб-приложения нас же интересует Как организовать поддержку нескольких языков для Системы Управления Контентом? На мой взгляд, это несколько другой уровень вопроса, хотя и не на много более сложный, как окажется при детальном рассмотрении.

суббота, 7 ноября 2009 г.

Быть или не быть?

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

А выбор таков -- Использовать уже готовые решения с минимальными доработками или выполнить задание непосредственно и с нуля (решение на базе фреймверка (без собственных наработок), я назову именно "с нуля").

вторник, 3 ноября 2009 г.

Основные трудности при разработке CMS

Вероятно, каждый веб-разработчик хотя бы раз, но задумывался о разработке своей CMS. И был уверен, что именно его разработка будет лучшей. Чтож я не исключение.

Главное -- понимать, что идеальных решений не бывает. И любая универсальная CMS уступает специально разработанному приложению для решения конкретной задачи. По крайней мере при решении основного ТЗ проекта.

Приложение, решающее конкретное ТЗ должно все равно писаться из расчета необходимости расширения в будущем. Вот тут и получается, что все равно пишется приложение так как буд-то это узко направленная CMS.

суббота, 31 октября 2009 г.

"Первая система" или "Первый блин комом"

Первая система появилась на свет год назад в результате работы в небольшой веб-студии. Т.к. молодой и горячий программист (я) не захотел разбирать чужие глюки в существовавшей CMS. Старая система, была действительно старой. Имела дикую организацию и множество кнопочек с пометкой "В разработке" (которую естественно ни кто уже давно не вел). Сейчас я уже не вспомню деталей той системы, но было очевидно не только для меня, но и руководства, что фирма нуждается в новой CMS. И я приступил к разработке.

В тот момент я делал только первый шаги в web-программировании (по крайней мере, теперь я это отчетливо понимаю, до этого было 7 лет программирования для Windows). Я рассматривал различные фреймверки для ускорения разработки, какие-то казались невероятно сложными, другие были откровенно дубовыми, на счет третьих возникали сомнения в быстродействии. Выбор свой остановил на CodeIgniter.
И начался процесс разработки и одновременно осваивание фреймверка -- граблей нашел много. В тот момент еще не нашел/не заметил русскоязычного сообщества и потому все трудности решал самостоятельно. Путь был тернист, но я его прошел...

среда, 28 октября 2009 г.

Начало

По правде говоря, это моя вторая попытка вести блог. Не знаю почему первая не удалась, но для этого блога есть конкретная цель
поделиться своим опытом изобретения велосипеда под названием Своя CMS.


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

Замечу, что основное повествование будет об идеях реализованных в моей уже второй CMS. Первая была написана год назад и оглядываясь на неё, я понимаю, что то, что было реализовано тогда больше похоже на сравнительно гибкое приложение для показа html-документов.

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