Подпишитесь на RSS, чтобы всегда быть в курсе событий.
Комментарии
- Denis: Попробуйте обновить кэш
- porcelanosa: У меня почему-то ничего не появилось — т.е. после применения к странице шаблона — ничего не...
- Mark Hamstra: I used Google Translate to read this post, and just wanted to add that those issues should have been...
- безимени: все было бы прекрасно если бы не гигантское количество грамматических ошибок. Серьезно. Глаза режет
- Vasiliy Ivanov: Уже есть рабочий плагин, если готовы заняться — ради бога.=) Напишите только в разработчики...
Жизнь моя…
Прошедшая неделя оказалась не сильно богатой на события, но кое-чем хочется поделиться с читателями. Возможно это будет кому-то интересно. Во-первых, удалось договориться с одним человеком о сотрудничестве(ссылку на его сайт можете найти у меня в блоге). В ближайшее время на сайте должны появиться готовые шаблоны для MODx и SilverStripe Во-вторых, на следующей неделе решил написать [...]
jigoshop и робокасса или мой первый заказ для wordpress
Меньше недели назад в личку на фрилансе постучали с интересным предложением, нужно было подключить к одной из отечественных систем оплаты магазин. Движок wordpress плагин магазина jigoshop. Опыт разработки подобных плагинов у меня 4 года, правда под joomla по этому я согласился. Чуть позже общаясь через скайп, я выяснил что уже несколько человек пытались решить эту [...]
Метки
Ссылки
Проектирование сайта на MODx CMS несколько замечаний
(No Ratings Yet)
Loading ...Как и многое на этом сайте эта статья написана на основе практического опыта и работы над сайтами многих клиентов. Сразу оговорюсь, что здесь нет ни каких откровений просто мои наблюдения.
Для начала поясню зачем это собственно надо.
В моей практике часто встречаются сайты в которых добавление нового раздела или документа представляет определенные сложности, это связанно с тем, что практически все ссылки прописаны просто с использованием конструкции [~id~](или [[~id]] для Revo) и добавление нового пункта меню представляет собой блуждание по шаблонам. Апофеозом был случай когда таким образом было сделано меню на 2500(!) элементов(это конечно уже патология)
Использование чанков и javascript может немного изменить ситуацию, но только до момента когда потребуется сложная навигация с отображением активного пункта меню.
При этом когда начинаешь исправлять этот сайт понимаешь что документы хранятся не структурировано и использовать стандартные сниппеты для работы с ними не представляется возможным приходится придумывать решение на лету.
В связи с этим несколько советов по поводу того, как спроектировать сайт что бы потом не было проблем с его дальнейшим развитием.
1 часть Head
В этой части подключаются стили и скрипты, используемые на сайте, большая часть из которых повторяется на всех страницах сайта(берем случай когда на сайте используется несколько шаблонов). И часто программисты вносят всю эту часть в отдельный чанк. В принципе всё правильно, но при этом они выносят в тот же чанк и тэги<head>…</head> На первый взгляд ни чего страшного, но представим себе ситуацию когда вам требуется для одного из шаблонов добавить дополнительные скрипты, например, фотогалерею по хорошему один или два скрипта и один файл со стилями. Если вы внесли тэги <head>…</head> в чанк то вам придется создать ещё один для нового шаблона. Пока вроде всё нормально ни чего страшного не предвидится, но если вам придется вносить правки в чанки с заголовками(допустим вы хотите сменить способ формирования заголовка страницы) вам придется править два чанка, а если их больше? По этому обычно заголовок я выношу в конструкцию типа:
<head> [[$head]] </head>
2 Шаблоны
Здесь то же можно привести пару наблюдений, во-первых, все повторяющиеся в разных шаблонах части, лучше выносить в отдельные чанки, это одно из их главных назначений. Во-вторых, попытка впихнуть всё в один шаблон, т.к. потом при расширении функционала сайта иногда требуется возможность выбрать документы по определенному признаку например: все галереи и не всегда есть возможность сделать их потомками одного документа. По этому я предпочитаю в случае если функционал страницы может повториться более одного раза выносить её в отдельный шаблон.
3 Навигация и структура сайта
Вот здесь приходится сталкиваться со всем богатством фантазии разработчиков. Поместить все документы в корень, сделать один скрытый контейнер в котором лежат все элементы сайта, поместить документ главной страницы на третий или четвертый уровень вложенности, продолжать я могу очень долго, но как то не хочется. Что здесь можно сказать, продумывайте структуру сайта до того как начинаете что-либо на нем делать. Человеку зашедшему в админку сайта должно быть понятно, где что валяется и как здесь что организованно. В тех редких случаях когда удавалось пообщаться с людьми которые сделали экзотичную структуру сайта, в большинстве случаев отвечают, что так проще для навигации и wayfinder’a но есть же множество других способов создания навигации и жертвовать структурой сайта, ради одной только навигации я считаю глупо. По этому обычно я сначала выделяю основные разделы сайта, например: новости, статьи(в которых то же могут быть подразделы), галереи и т.п, а потом выстраиваю систему навигации.
4 Используйте стандартные средства
Среди разработчиков часто встречается почти маниакальное желание сделать все не стандартными методами, типа стандартные средства не совершенны да я сам всё быстрее сделаю чем буду документацию разбирать, варианты можно приводить опять же до бесконечности. Каюсь и сам одно время разрабатывал все решения с нуля. Что же мы получаем в результате.
Во-первых, не факт, что разработка собственного решения займет мало времени, обычно получается с точностью до наоборот.
Во-вторых, поддержка кода. Представим себе ситуацию что через два месяца после сдачи сайта появляется новая технология, а ещё через месяц стандартные компоненты начинают её во всю поддерживать. Заказчик просит сделать себе так же, как у конкурентов, а у вас мало того что нет времени, так ещё и для поддержания этой технологии требуется переписать половину компонента, а время на это есть не всегда.
По этому здесь можно дать только забитый совет. Не надо изобретать велосипеды на сайтах заказчиков. Если чешутся руки сделайте это в свободное время на своем собственном проекте. Если возможности реализовать желания заказчика стандартными способами нет, делайте всё максимально гибким и настраиваемым.
В принципе всё. Вот четыре правила которые могут сильно облегчить жизнь вам и тем кто будет дорабатывать ваши сайты. Если кто-нибудь захочет что-нибудь добавить милости прошу в комменты.
Читайте так же:
Рубрики
Архивы
- Май 2012
- Февраль 2012
- Январь 2012
- Ноябрь 2011
- Октябрь 2011
- Июль 2011
- Июнь 2011
- Май 2011
- Апрель 2011
- Март 2011
- Февраль 2011
- Январь 2011
- Декабрь 2010
- Июль 2010
- Июнь 2010
- Март 2010
- Февраль 2010
- Январь 2010
- Декабрь 2009
- Ноябрь 2009
- Октябрь 2009
- Сентябрь 2009
- Август 2009
- Июнь 2009
- Май 2009
- Апрель 2009
- Март 2009
- Февраль 2009
- Январь 2009
