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

Комментарии

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

Следующим пунктом с которым мне удалось разобраться был поиск. Для установки поисковой формы на сайт ни каких особо сложных действий не требуется Для начала правим шаблон. В том месте где должна стоять поисковая форма просто пишем $SearchForm после чего необходимо поправить таблицу стилей для этой формы сама форма имеет класс SearchForm_SearchForm соответственно поле ввода можно [...]


30 Апрель 2011 · 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 или более баннеров, т.е. код места не меняется, меняется то что в нем показывается.
    Вероятно запутанно объяснил :)

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

Счетчик