Последнее обновление: 10.02.2013 в 21:16
Подпишись на RSS
rss Подпишитесь на RSS, чтобы всегда быть в курсе событий.

Комментарии

Присоединяйтесь к обсуждению
  • Евгений: Доброго времени суток. Кто-то подскажет, как правильно настроить вывод мета-тэгов в результатах поиска. На...
  • Евгений: Доброго времени суток. Возник вопрос по специфике движка SilverStripe. Есть основное зеркало сайта вида...
  • Вадим: Спасибо помогло, сделал так date_timezone = Europe/Kiev
  • John Doe: Не помогло, шаблон все ровно всегда такой же как у главной страницы ((
  • Алексей: Здравствуйте. Спасибо за статью. Собираюсь осваивать MODx (сейчас сижу на WP) и статья очень пригодилась!...
27 Ноябрь 2009 · о работе

После того, как написал предыдущий пост на тему SS ни как не удавалось сесть и нормально поработать с этой системой. Постоянно то переговоры с заказчиками, то работа над результатами этих самых переговоров. Но время на то, что бы поработать с системой нахожу всегда. Итак далее небольшой опус на тему достоинств и недостатков, плюс немного про [...]


1 Январь 2010 · MODx, Без рубрики

В общем сейчас пришел ответ от издательства, по поводу перевода всей книги «MODx Web Development». По поводу разрешения перевода одной главы не слова, но про перевод всей книги есть два предложения либо выкупать права на перевод и издательство, либо поговорить о переводе с одним из наших из наших издательств(обещали прислать адрес издательства). Я остановился на [...]


7 Январь 2012

Проектирование сайта на MODx CMS несколько замечаний

Рубрика: MODx. Метки: , ,
Vote This Post DownVote This Post Up (No Ratings Yet)
Loading ... Loading ...

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

Для начала поясню зачем это собственно надо.
В моей практике часто встречаются сайты в которых добавление нового раздела или документа представляет определенные сложности, это связанно с тем, что практически все ссылки прописаны просто с использованием конструкции [~id~](или [[~id]] для Revo) и добавление нового пункта меню представляет собой блуждание по шаблонам. Апофеозом был случай когда таким образом было сделано меню на 2500(!) элементов(это конечно уже патология)
Использование чанков и javascript может немного изменить ситуацию, но только до момента когда потребуется сложная навигация с отображением активного пункта меню.
При этом когда начинаешь исправлять этот сайт понимаешь что документы хранятся не структурировано и использовать стандартные сниппеты для работы с ними не представляется возможным приходится придумывать решение на лету.

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

1 часть Head
В этой части подключаются стили и скрипты, используемые на сайте, большая часть из которых повторяется на всех страницах сайта(берем случай когда на сайте используется несколько шаблонов). И часто программисты вносят всю эту часть в отдельный чанк. В принципе всё правильно, но при этом они выносят в тот же чанк и тэги<head>…</head> На первый взгляд ни чего страшного, но представим себе ситуацию когда вам требуется для одного из шаблонов добавить дополнительные скрипты, например, фотогалерею по хорошему один или два скрипта и один файл со стилями. Если вы внесли тэги <head>…</head> в чанк то вам придется создать ещё один для нового шаблона. Пока вроде всё нормально ни чего страшного не предвидится, но если вам придется вносить правки в чанки с заголовками(допустим вы хотите сменить способ формирования заголовка страницы) вам придется править два чанка, а если их больше? По этому обычно заголовок я выношу в конструкцию типа:

<head>
[[$head]]
</head>

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

3 Навигация и структура сайта

Вот здесь приходится сталкиваться со всем богатством фантазии разработчиков. Поместить все документы в корень, сделать один скрытый контейнер в котором лежат все элементы сайта, поместить документ главной страницы на третий или четвертый уровень вложенности, продолжать я могу очень долго, но как то не хочется. Что здесь можно сказать, продумывайте структуру сайта до того как начинаете что-либо на нем делать. Человеку зашедшему в админку сайта должно быть понятно, где что валяется и как здесь что организованно. В тех редких случаях когда удавалось пообщаться с людьми которые сделали экзотичную структуру сайта, в большинстве случаев отвечают, что так проще для навигации и wayfinder’a но есть же множество других способов создания навигации и жертвовать структурой сайта, ради одной только навигации я считаю глупо. По этому обычно я сначала выделяю основные разделы сайта, например: новости, статьи(в которых то же могут быть подразделы), галереи и т.п, а потом выстраиваю систему навигации.

4 Используйте стандартные средства

Среди разработчиков часто встречается почти маниакальное желание сделать все не стандартными методами, типа стандартные средства не совершенны да я сам всё быстрее сделаю чем буду документацию разбирать, варианты можно приводить опять же до бесконечности. Каюсь и сам одно время разрабатывал все решения с нуля. Что же мы получаем в результате.
Во-первых, не факт, что разработка собственного решения займет мало времени, обычно получается с точностью до наоборот.
Во-вторых, поддержка кода. Представим себе ситуацию что через два месяца после сдачи сайта появляется новая технология, а ещё через месяц стандартные компоненты начинают её во всю поддерживать. Заказчик просит сделать себе так же, как у конкурентов, а у вас мало того что нет времени, так ещё и для поддержания этой технологии требуется переписать половину компонента, а время на это есть не всегда.
По этому здесь можно дать только забитый совет. Не надо изобретать велосипеды на сайтах заказчиков. Если чешутся руки сделайте это в свободное время на своем собственном проекте. Если возможности реализовать желания заказчика стандартными способами нет, делайте всё максимально гибким и настраиваемым.

В принципе всё. Вот четыре правила которые могут сильно облегчить жизнь вам и тем кто будет дорабатывать ваши сайты. Если кто-нибудь захочет что-нибудь добавить милости прошу в комменты.

Читайте так же:



  • http://lexxiy.ru Алексей

    Здравствуйте.
    Спасибо за статью. Собираюсь осваивать MODx (сейчас сижу на WP) и статья очень пригодилась!
    Есть вопрос (маниакальный :) ) можно ли сделать часть структуры (вероятно специально для этого выделенную) которое будет выводиться например на главной, в виде блоков но по факту будет являться контейнером для тех элементов которых на это место назначишь.
    Как пример можно считать код баннерного места, на который можно прицепить 1 или более баннеров, т.е. код места не меняется, меняется то что в нем показывается.
    Вероятно запутанно объяснил :)

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

Счетчик