Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее.
Ну так чем она сложнее, тем актуальнее то, о чем я говорю. Если на сайте много разношерстных лейаутов, умножение их на «экраны» (т.е. наборы одновременно отображаемых блоков) может привести к анархии.
В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
В нашей CMS это будет выглядеть так:
<div class="sidebar" fx:area="sidebar"></div>
:) Это все, что тут требуется от шаблона. Дальше все делается мышкой, порядок такой:
Идем на главную, жмем «добавить блок сюды» в сайдбаре. Выбираем нужный тип блока для рекламы на главной, в поле «Где показывать» — «Только эта страница».
Идем на любую внутреннюю, опять жмем «добавить блок», выбираем блок, в поле «Где показывать» — «Только потомки страницы „Главная“» (т.е. все внутренние).
Идем на страницу категории, все то же самое, «Где показывать» — «Потомки раздела „Магазин“, имеющие тип „Категория товаров“».
Итого: блоки стоят где надо, в нужном порядке, без правки шаблона. Пункты 1 и 2 можно объединить в один блок, зависит от реализации крутилки (надо ли настраивать место показа на уровне отдельного банера).
Я не очень понял, как добывать акции. Я сегодня слишком мало спал, чтобы прямо сейчас расшифровать этот чем-то похожий на perl лаконичный и понятный синтаксис. Вот этот [*actionsids*] — его значение откуда берется? Оно какого типа?
Как вариант, если считать, что акции лежат где-то отдельно (например, в разделе «Новости»):
У «Акции» добавляем поле «Связанная категория каталога» (тип поля — «связь с другим объектом», в форме будет выглядеть как поисковая строка с ajax-подсказками).
При добавлении блока на страницах категорий выбираем тип «Данные по фильтру» — «Услуги». Во вкладке «Условия» добавляем условие, в первой выпадушке выбираем поле «Связанная категория каталога», во второй — «Текущая страница».
Можно даже сделать, чтобы у акции было несколько категорий. Примерно так же, только кликов больше =) Трюк со значением «текущая страница» в условии не пройдет, если мы хотим показывать блок не только на самой странице категории, но и внутри нее (например, на странице товара). Но про такой кейс мы помним и, как только будет, на чем наглядно показать, мы его реализуем, добавив во вторую выпадушку варианты «ближайший предок, имеющий тип...» + выбор типа, и «предок N-го уровня (название)», собственно, находящий нужный элемент сверху вниз по хлебным крошкам. (Я начинаю понимать, почему начальство меня часто спрашивает, точно ли у нас не получится что-то типа друпала, снова эта картинка).
Кстати, а в ModX этот сценарий разруливается?
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
Ну так вы же не спорите =) я это и написал — такой подход проще, ибо очевиднее. Вопрос только в цене.
А у меня таких заказчиков большинство.
Значит вы мало сил уделяете воспитательной работе. Открою секрет, большинство клиентов (как минимум в Мск.) готовы не задумываясь отдать за хостинг сумму где-то между топовым VPS и дохленьким дедиком, лишь бы работало. Если есть знакомые из веб-студий — поспрашивайте, кто почем продает хостинг, очень удивитесь.
ok, пример немного утрированный, всякие оформительские врапперы появляются не везде. Но появляются.
И здесь вопрос прежде всего в решении проблемы различия вёрстки от страницы к странице.
Это вам кажется, что вы решаете проблему различия верстки. На самом деле это другая проблема — различия набора данных. Верстка-то одна, хидер-контент-сайдбар-футер. Отличия в том, какие блоки показываются в «дырке» под названием «контент» и в том, показывается ли сайдбар. Это одна и та же верстка, которая немного меняется в зависимости от пришедшего набора данных. Ваш подход приведет к тому, что для всех типов страниц, где есть сайдбар, придется копипасить вот это:
<div class="ws">
<div class="side">{{side}}</div>
У нас же оно существует в единственном экземпляре и разруливается добавлением довольно простой логики:
<!-- @fx:omit - не показывает тег, если выполнилось условие, но показывает все, что внутри -->
<div class="ws" fx:omit="!$sidebar">
<!-- @fx:if - не показывает тег и все что внутри, если не выполнилось условие -->
<div class="sidebar" fx:if="$sidebar">{$sidebar}</div>
...
</div>
Всего две проверки (или одна, если div.ws нужен не только при наличии сайдбара). Но мы больше нигде не размножаем этот код, он у нас целиком под контролем. Если завтра дизайнер нарисует нечто такое, что не реализуешь без пяти врапперов, мы добавим их в одном единственном месте, а не будем бегать по шаблонам.
Притом, в чанке side может быть определена логика показа блоков не просто на той или иной странице, а на том или ином типе страницы
А у нас в шаблоне вообще не бывает никакой логики показа чего-либо, кроме генерируемой шаблоном разметки :) Это не дело шаблона, решать, что показывать. Это другой слой. У нас. Я понимаю, почему у ModX (и у многих других) по-другому, подход с «активным типизированным шаблоном» проще и очевиднее, но офигительно проигрывает в гибкости.
Это о предположительно паре десятков строк?! Вы шутите? Писать модель-контроллер ради функционала, который пишется на коленке и сломаться не может по определению, поскольку там просто нечему ломаться? Вы меня, конечно, простите, но я бессменно уже несколько лет ржу в голос над такими «серьёзными пацанами», которые ради пары действий плодят килобайты, а то и десятки килобайт говнокода; которые ради того, что можно сделать вообще статикой подключают массивные фреймворки. О дальнейшем развитии проекта хотите спросить? А вот как раз здесь нужно думать, где стоит утягивать пол-гитхаба под проект, а где достаточно наговнокодить пару десятков строк.
Не буду спорить. Я сам не брезгую «быстрыми грязными решениями», и вообще «наговнокодить по-быстрому» — это очень ценное для бизнеса умение :) Просто надо понимать, что такие решения — именно «грязные». При этом нормальные платформы стараются сокращать оверхед на организацию всего по феншую (генераторы + соглашения), и цена того, чтобы сделать все сразу как надо, на самом деле, не очень велика, особенно когда выработана соответствующая привычка.
То, что Вы сейчас описали — это базовая парадигма функционального программирования.
Ох, ну нет же =) То, что я описал — это «декомпозиция для чайников» :)
Насчёт несущественности экономии места — расскажите это владельцам аккаунтов на шаред-хостингах, которые держат по десятку магазинов.
Я таких очень давно не видел, но знаю, что они есть. Кстати, именно по этой причине мы стараемся до последнего не расширять стек используемых технологий, и, в частности, не пускаем в проект ноду ни в каком виде :) Кому надо — приделают, но из коробки оно работает с минифайером и компайлером less, написанными на голом PHP, соответственно, на шареде тоже заведется.
Нравится идея отделить компоновку, конструирование облика сайта от процесса наполнения-редактирования. Это сильно разные виды деятельности, разные этапы жизни сайта.
Безусловно. Настолько разные, что у нас долгое время было два режима: «Редактирование» для правки контента и «Дизайн» для добавления/настройки блоков. Мы их в итоге объединили, потому что собственно контент тоже может состоять из блоков (например, если нужно собрать лонг-рид из множества этажей, с каверами, врезками, галереями и т.д.). А режим «Дизайн» люди не видели и не понимали. Поэтому сейчас все контролы доступны в «Редактировании». Но мы планируем все-таки решить задачу их разделения, через систему прав — «крутой» пользователь может добавлять любые блоки куда угодно, а «редактор» — только на созданные им страницы в ограниченный набор областей, примерно так.
Полагаю, что облик и отступы должен придумывать дизайнер, а пользователь выбирать шаблоны и вводить тексты.
Мы тоже так считаем. Но на практике, когда даешь пользователю выбирать, дизайнеру и верстальщику приходится решать много очень тонких и интересных задачек, продумывая, как тот или иной шаблон будет вести себя в разных окружениях. Нам в этом очень помогает БЭМ-методология, но даже ее кунг-фу местами не хватает. Например, когда друг в друга оказываются вложены одноименные блоки (набор колонок, вставленный в другую колонку), или когда внешний вид элемента зависит от контекста, куда помещен блок (текст шрифта меню должен быть белым, если меню стоит в шапке, или черным, если меню попало куда-то еще). Пока такие задачки решаются не очень системно. Планирую грузануть ребят из Яндекса, когда наберется достаточно подобных головоломок =)
Хм… Интересно, сколько весит Ваша система в итоге?
Ну вот последняя собранная версия — 5мб в архиве, вместе с демо-сайтом (который включает штук 40 больших картинок).
Каталог в том же MODX делается без кодинга вообще.
…
нужно просто воткнуть параметр (несколько символов) в нужное место шаблона
Если не считать правку шаблона кодингом, у нас можно «без кодинга вообще» сделать очень много всего :) Но все-таки правка шаблона — это кодинг.
Но коли уж Вы оговорились, что кодинг в Вашей системе нужен только для реализации специфичного поведения обработчика, то ОК, посмотрим на практике.
Смотрите, поскольку прямо сейчас я не могу показать код и инструменты разработчика, это не очень предметный разговор. Давайте, если вам интересно, вы придумаете какой-нибудь заковыристый кейс, а когда мы выпустим полноценный релиз в паблик — я его обязательно разберу в подробностях.
А нервный тик у меня вызывает система, в которой логика шаблонов бесструктурна и непрозрачна.
Я могу только сказать, что у нас логика шаблонов структурна и прозрачна =) См. выше — следите за новостями, в обозримом будущем все покажем. QuadBraces видел, да. Идея интересная. Я сам думал над тем, чтобы сделать наш шаблонизатор целиком отчуждаемым, но сейчас он много где завязан на наши модели из-за необходимости делать прозрачный edit-in-place, и вынесение этого слоя куда-то в наружу — довольно тонкая хирургическая операция.
Например, у меня будут общие для всех страниц хедер и футер. А контент будет отображаться в зависимости от шаблона. И не свитчами в одном файле, а именно чанками.
Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика. Шаблон, состоящий из 10 открывающих тегов — это плохо. Если хидер-футер есть везде и всегда идут парой — это один шаблон. А контент вообще не должен зависеть от шаблона, контент — это то, что приходит снаружи. Если «шаблон» — это обвязка + вызовы какого-то исполняемого кода, то это не шаблон, а «экран», «тип страницы» или еще как-то. В этом случае понятно, почему у вас их получается «порядка десятка разных». У нас это именно шаблон, данные в который приходят снаружи (и настраиваются путем добавления блоков в нужные области). Если совсем упростить, то так:
{* вот это - шаблон *}
<html fx:template="layout">
<head>...</head>
<body>
<header>{$header}Default header{/$}</header>
<section>{$content}</section>
<aside fx:if="$aside">{$aside}</aside>
<footer>{$footer}</footer>
</body>
</html>
{* и его можно сколько угодно раз вызывать, передавая нужные данные *}
{* из другого шаблона: *}
{call layout with $content = 'hello world', $footer = 'все права защищены' /}
{* или из php: *}
echo fx::template('layout')
->render([
'header => 'opps',
'footer' => get_oops_footer(),
'content' => 'oh shi',
'aside' => get_oops_nav()
]);
Это не совсем настоящий код — обработка лейаута происходит глубоко внутри, и явно вызывать его шаблон не нужно, а вместо переменных в лейауте используются области для расстановки блоков. Но принцип именно такой: шаблон хранит разметку, в которой есть точки, позволяющие вывести данные, пришедшие снаружи. А не вызовы кода, который сам добывает данные.
Ради того, чтобы дёрнуть с партнёрского сайта крохотную XML-ку и вывести информацию из неё в какое-то место сайта, плодить контроллеры и модели? Жуть какая!
Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак :) Есть немало людей, которые к этому еще и пачку тестов напишут. И будут по-своему правы. Если есть стопроцентное понимание, что этот код одноразовый, его можно писать как угодно. Но практика показывает, что одноразовый код, во-первых, тоже имеет свойство ломаться, и если он написан «как попало», заметить и починить поломку будет сложнее. Во-вторых, одноразовый код иногда внезапно оказывается нужен где-то еще с немного другими параметрами, и тогда тоже начинаются приключения.
Повторное использование кода, кстати, это очень актуальный вопрос. Допустим, у меня есть десять проектов на одной и той же CMS. Как у вас обстоят дела с повторным использованием кода ядра CMS, дабы не хранить его в 10 экземплярах на хостинге?
Обычно под повторным использованием подразумевается немного другое — когда для реализации отличий в поведении не нужно копипастить код целиком и править нужное место, а достаточно передать необходимые параметры.
Хранить много экземпляров не обязательно. Во-первых, система поддерживает мультисайтовость. Если сайты похожи и управлять ими должны примерно одни и те же люди — просто заводим все на одной копии. Если сайты сильно отличаются, можно цеплять ядро системы и модули при помощи симлинков, это будет работать. Собственно, демка, которую мы тут показываем, именно так и работает — причем у нас остается техническая возможность управлять подключенными модулями для каждого сайта отдельно.
Но вообще такой подход имеет много недостатков, и без крайней надобности лучше им не пользоваться. Ядро системы и модули подключаются через Composer, и это дает гораздо больше гибкости и предсказуемости. А экономить на диске имеет смысл, когда речь идет о тысячах сайтов. Для десятков даже на дохлой VPS экономия будет не особо заметной.
Вижу, contenteditable. Если попробовать поработать с Вашим продуктом, скажем, в том же «ослике», оно будет работать? Вы уверены?
Нет, не уверены. Как можно быть в чем-то уверенным, когда речь за ослика? =)
Если серьезно, тут не должно возникать особых проблем. Поля типа «строка» жестко фильтруются от любого HTML, а поля «rich text» обрабатывает сторонний редактор (собственно, Redactor от Imperavi, мы купили OEM-лицензию). Он состоит из почти 10к строк кода, многие из которых содержат слово «msie», и можно надеяться, что наиболее вырвиглазные косяки они обрабатывают.
А если пользователь захочет изменить дизайн, к кому он должен обращаться — к Вашей компании или к любому программисту? Насколько легко осваивается создание/кастомизация шаблонов для Вашей системы?
К нашей компании есть смысл обращаться, если пользователь использует, например, стандартный шаблон, разработанный нами. Он может предложить улучшение. В остальных случаях ему следует обращаться куда-нибудь еще, потому что мы сами разработкой сайтов не занимаемся (ну, точнее, занимаемся, потому что нужны подопытные кролики, но не массово — в основном для знакомых). Но вообще сейчас рано об этом говорить и гадать на тему легкости кастомизации. Следите за новостями, сделаем полноценный запуск — сможете сами оценить =)
То есть для того, чтобы банально сделать анкетирование на сайте или простой каталог, нужно нагов… накодить ещё пару килограммов кода?
Не понимаю, о чем речь. Простой каталог и анкетирование приходится говнокодить независимо от платформы. Просто у платформ с историей это уже сделали (ну, не святой же дух зачал все эти друпал-модули?). А у нас все впереди.
Я говорил о другом. Если у вас уже есть что-то работающее, и вам понадобилось к нему новое поле, создать поле можно в браузере, а обработку придется добавлять в код. Собственно, в Modx оно так же устроено, можно добавить TV, но она не начнет магическим образом показываться на сайте где нужно и использоваться как нужно, пока это не будет описано в коде.
Именно поэтому я и советовал ещё раз пристально изучить MODX (притом именно Evolution, к Revo у меня самого масса претензий). Добавляем в Evo TV-параметр к шаблону и дело в шляпе. Он отображается в форме ресурса, прекрасно создаётся/сохраняется в базе и, если вывести переменную в шаблон, отображается. В сущности и кодить почти не приходится. А создать простейший фильтр на TV-шках — дело минут десяти и пары десятков строк кода в простом сниппете.
А я что пишу? Добавляем поле к компоненту (у вас это ресурс), и оно начинает отображаться в форме, сохраняться в БД, и, если вывести в шаблон — отображаться. Я ровно это и написал: чтобы вывести в шаблон, нужно править код шаблона. Код моделей/контроллеров надо править, если поле требует какой-то особой логики (правила валидации в модели, экшн для вывода с фильтрацией/группировкой по этому полю в контроллере и т.д.).
Кстати, новое поле без единой строчки кода будет доступно в настройках блока: во-первых, по нему можно будет сортировать списки (если тип позволяет), во-вторых — использовать поле в фильтрах блока-выборки (то есть можно сделать блок, в котором покажутся объекты, у которых значение поля больше-меньше-равно-содержит и.т.д. указанное значение).
Evolution изучу, спасибо.
Минуточку, а сама по себе концепция чанков у Вас реализована? Или написание шаблона под Вашу систему схоже с написанием шаблона под «неназываемую-от-которой-нервный-тик»?
А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД… =)
С написанием шаблонов под Джумлу нет ничего общего, но для неподготовленных и слабых духом оно может оказаться и пострашнее: контекст исполнения, мэтчинг шаблонов по предикатам… Я, знаете ли, пол жизни на XSLT писал, такое даром не проходит… )
У нас есть довольно мощный набор инструментов для повторного использования кода. Повторно использовать код можно не только при помощи чанков, если что ;)
Мне вот нужно вывести какую-то простейшую информацию с сайта друга, которую я дёргаю при помощи curl. Мне для этого нужно писать целый модуль?
Есть два «грязных» типа блока — «произвольный HTML» и «PHP+FloxML». Задумывались примерно для таких вещей, но пока не считаются «честными» решениями. Во-первых, это хранение кода в БД, см. выше. Во-вторых, пугало для пользователя.
«Целый модуль» — звучит угрожающе, но по сути там все то же самое. PHP-код, достающий данные, и код шаблона, их показывающий. Если никуда не спешить, можно PHP-код разделить на модель+контроллер, а если очень спешить — можно засунуть получение данных прямо в шаблон (curl жирновато, но дернуть file_get_contents('http://...') пока можно, выражения не фильтруются). Суть та же.
Привет, спасибо, о типографике мы уже =) Вот пример с домашними: joxi.ru/a2XQZnWcq57aAg 3-4 строками я продублировал то же самое, но с подчерком вместо пробела, чтобы показать что пробел+предлог умещаются в строку. На видео это не понятно, потому что предлог переносится просто из-за нехватки места в строке.
Ну и кавычки-ёлочки, и mdash тоже. Одна (временная) проблема, пока не успели прикрутить к формам, работает только при иплейсном редактировании.
Использован типограф Дениса Селезнева github.com/typograf/typograf Для работы в realtime его пришлось пропатчить, сделав компиляцию регулярок одноразовой и изменив несколько правил, которые давали неожиданный результат на границе текста (типограф изначально рассчитан на ситуацию «текст уже написан, теперь мы его типографируем», а тут надо типографить прямо в процессе набора).
Как только найдется время осмыслить, как эти изменения могут повлиять на штатную работу, обязательно оформим pull request.
Спасибо за интерес к нашей цмске. Постараюсь ответить по пунктам.
1. Программная архитектура обычному пользователю не интересна. Однако, как быть с программистами, обслуживающими сайт? Насколько система понятна обычному веб-программисту? Есть ли API, документация? Возможно ли создавать дополнительные модули?
У нас пока нет достаточной статистики, чтобы утверждать, что система понятна обычному веб-программисту. Но есть все предпосылки надеяться, что так и будет. Жизнь покажет, следите за новостями =) Пока мы только хотели показать пользовательский интерфейс, посмотреть, как люди будут на него реагировать. Кстати, спасибо Хабру, данных для анализа набралось немало.
API, разумеется, есть. Документировать его пытались непосредственно в коде. Замахнулись на мировое господство и стали писать сразу на английском языке. Некоторое время спустя результат пришлось почти целиком выпилить, поскольку уровень английского в среднем по команде не дотягивал до презентабельного. Мы решим эту проблему. И мануалы напишем, уже есть черновики для внутреннего использования.
Можно создавать свои модули и темы. Система реализует следующие сценарии расширения:
— добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);
— добавление полей к существующим типам и их обработка (пример: добавить всем страницам поле, отвечающее за og:image и вывести его);
— изменение поведения существующих компонентов через систему событий (при удалении или изменении элементов указанного типа отправлять на почту админу предыдущее состояние элемента);
— изменение поведения контролов системы на клиенте через JS API (типограф, который можно наблюдать в демке — самостоятельный модуль);
— добавление новых шаблонов для существующих блоков;
— кастомный роутинг для динамики.
Собственно, на данный момент создание модуля — единственный способ что-то напрограммировать: у нас нету того, что обычно называется «Application», вместо этого создается модуль «App» вендора «My», куда складываются специфичные для проекта штуки.
2. Подход полного WYSiWYG безусловно удобен для пользователя. Беда в том, что в итоге получается едва ли не как в MS Word. Там тоже можно страницы создавать. Вот только по итоге там столько мусора в итоге оказывается. Проблему избыточности генерируемого WYSIWYG-кода решили?
Посмотрите внимательно на наш WYSIWYG =) Он — не совсем то, что обычно понимают под этим набором букв. Традиционно, «визивиг» условно эквивалентен понятию «rich text editor», но если вслушаться в расшифровку, станет ясно, что это не инструмент, а принцип. Причем, что самое забавное, очень часто традиционные WYSIWYG-редакторы этот принцип нарушают: если разработчик серией специальных магических пассов не подтянул в редактор нужные CSS, пользователь будет «see» в редакторе не совсем то, что он «get» на выходе :)
Так вот, мусорная разметка обычно появляется в двух случаях:
1. Ее создает rich text editor, когда пользователь пытается нащелкать в окошке TinyMCE какую-то сложную конструкцию;
2. Ее создает слой сайт-конструктора, когда пользователь мышкой двигает блок по холсту и крутит паддинги-маргины.
Оба случая возникают из-за плохой декомпозиции данных. Вместо внесения данных пользователь занимается «накликиванием дизайна», вместо управления контентом — управлением «кусками HTML». В нашей парадигме такого происходить не должно: данные разбиваются на поля при создании компонента, их отображение продумывает дизайнер и верстает верстальщик. Пользователю остается только выбрать подходящий вариант оформления исходя из бизнесовых задач, исходя из важности и устройства контента. Конечно, для этого тоже требуется некоторый вкус и чутье, но это значительно проще, чем когда приходится «фотошопить в браузере».
Что касается непосредственно текстового редактора: мы реализовали управление набором его кнопок и слегка «проредили» дефолтный набор. Может выкинем еще парочку =)
3. Как обстоят дела с масштабируемостью данных? Допустим, есть пользователи. Каким образом, если это вообще возможно, добавлять дополнительные поля БЕЗ лишних тонн… программного кода? Тот же вопрос про дополнительные поля страниц и дополнительные модели.
Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов. Хотя есть варианты, как выводить поля без участия программиста. Пока остается открытым вопрос, найдется ли достаточное количество кейсов для этой задачи. Потому что UI рискует получится «не очень прозрачным» [тут должна быть картинка, которая находится по запросу «drupal learning curve»] ;)
Резюмируя сказанное прежде всего хочу отметить, что в большинстве случаев заказчик сайта доверяет дело программисту/веб-разработчику/вменяемому (или не очень) фрилансеру, не заботясь о стилях.
Так и должно быть, так и у нас. Единственный нюанс — для типовых проектов наемного разработчика в этой модели может заменить разработчик, собравший типовое решение (модуль, тему или целый готовый сайт).
Системы, ориентированные исключительно на пользователя, уже создавались. Ничего хорошего из этого не вышло. Взять хотя бы «джумлу», от одного упоминания о которой у меня начинается икота и нервное дёргание глазиком.
Честно сказать, я не очень понимаю, каким местом джумла ориентирована «исключительно на пользователя», зато хорошо понимаю ваши эмоции =) В бытность фрилансером сам пару раз сталкивался (хотя давно это было). Ориентированность на пользователя — это уж скорее про Wordpress, считается, что он завоевал популярность благодаря своей понятности и доступности. Которых, впрочем, ему изначально было проще добиться из-за узкой специализации.
В качестве примера изучите MODX Evolution. Это как раз система, которая и для пользователя удобна и программисту доступна и удобна.
Про Evolution не помню, а Revo ковырял довольно плотно. И к нему у меня есть претензии, хотя озвучивать их прямо здесь, наверное, не стоит. Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной, хотя соблазн их размножить — был :)
Их не так уж много. Самое разнообразие — контролы отдельных полей:
— datepicker
— управление картинкой
— панелька с кнопками wysiwyg
— выбор связанной сущности для полей-связей (мы его называем livesearch)
— текстовый инпут, если значение поля попадает в атрибут (например, адреса для произвольных ссылок)
Контролов блока еще меньше:
— настроить
— удалить
— перетащить
Некоторая печаль происходит, когда все это добро группируется на одной ноде (блок, состоящий из одного элемента, всю площадь которого занимает одно поле, например картинка). В этом случае весь зоопарк нужно уместить в одной панельке.
находятся все время в разных местах
Самый самый первый вариант интерфейса как раз помещал все кнопки в одну фиксированную плашку в верхней части экрана. Причем мы к такому варианту даже возвращались. Но так теряется ощущение контекста, к тому же приходится делать много движений мышью.
Нынешняя контекстная панелька появляется сразу над выделенным элементом и прижимается к левому краю, это сравнительно предсказуемое и интуитивно ожидаемое поведение. Неожиданное случается, если верхний-левый угол занят. Например, элемент большой по высоте и его верхушка уходит за верхний край экрана, панелька уйдет вниз при наличии там свободного места, либо прилипнет к верхней части экрана, пока место не появится. Подумаем, как проработать этот момент.
И ведь все равно приходится делать «панельки» для редактирования элементов, которых нет в явном виде на странице. Даже не метатеги, а скидки, проценты, сопутствующие товары и т.п.
Мы выделили два основных сценария. Для создания «чего-то большого» с нуля — формы, т.к. их проще линейно заполнять и сложнее что-то пропустить. Для быстрых правок «на лету» и для добавления «чего-то не слишком большого» (типа текста-с-картинкой, телефона, отдельной фотки) — визивиг.
Кроме того, визивиг позволяет вообще не решать два извечных вопроса:
1) вот эта хреновинка — это которое поле формы?
2) вот это поле формы — это что за хреновинка? =)
Сочетание визивиг и панели управления с формами расщепляет сознание.
Это они у нас еще не до конца «поженились» )) Сейчас при работе с панелью изменения показываются, но тут же перейти к инплейсному редактированию нельзя. Мы склонны считать, что это скорее бага =)
Представляется более привлекательной концепция «панель управления со своим стандартным дизайном, где есть все крутилки», но изменения отображаются сразу(на соседней половине страницы, фрейме, соседнем окне) и можно прикинуть как замена заголовка повлияет на вид «предварительного просмотра».
Да, изменения отображаются и сейчас, но иногда сам редактируемый узел оказывается под формой-панелью, и его тупо не видно. Мы много думаем над решением этой проблемы. Очевидный вариант — закатать все в ифреймы и не перекрывать контентную часть, а сжимать ее — но при этом теряется pixel perfect. Не очень большая беда, но все-таки. Два других варианта — приделать к панельке контрол, позволяющий ее быстро прятать/показывать/сужать (примерно как у wix), либо показывать ее слева или справа в зависимости от того, где расположен редактируемый узел (снижает предсказуемость, не работает для узлов, занимающих всю ширину).
При этом фронтенд может быть любой сложности.
Даже без визивига есть ограничения — элемент нужно элементарно выбрать и сделать, чтобы он никуда не убегал (привет, слайдер! =)). Чтобы показать кнопку редактирования. Без этого можно обойтись, если дублировать где-то в слое админки все элементы в табличном виде, эдакая админка-в-панельке. Но это, опять же, уводит нас от контекста, плюс возникают проблемы с редактированием данных, попавших на страницу через разнообразные выборки-зеркала (последние новости, лучшие комментарии и т.д.).
То есть сделать условно-контекстную админку с табличными списками — можно, и наверное нужно, иногда работа с данными в таком виде гораздо удобнее. Но не как единственный-основной способ получения доступа к контенту.
P.S. Долго пытался вспомнить, где же я видел человека в шлеме. Вспомнил: вот здесь! Ах, милая я.рушка… Почти восемь лет, однако =)
P.P.S. Еще раз спасибо за комментарий по существу. Надеюсь, по размеру моего ответа остальные хабражители поймут, насколько сильно мы хотим поговорить о нашем интерфейсе, и тоже что-нибудь про него расскажут или спросят =)
Сторонние компоненты общего назначения мы как раз планируем использовать — сейчас в очереди на переработку стоят наши «велосипедные» сервисы: логгер, кэшер и http. Хотя оно все немножко «сбоку».
Спасибо за совет. Сначала шрифт действительно грузился с сервера Mozilla, но я заменил на Google Fonts, решив, что так он с большей вероятностью будет отдаваться из кэша. Обязательно сравню, отдают ли они разные шрифты, и, если да — верну как было. Спасибо!
Шаблонизатор тут не может быть никаким другим, это специфика нашего подхода к редактированию: нужно протащить через шаблон всю необходимую мета-информацию, причем не добавляя в результирующий HTML лишних узлов и не заставляя кодера писать все мета-данные руками.
Поддерживаемость зависит от коммьюнити гораздо больше, чем от технологического стека, и тут нам пока, действительно, хвастаться нечем, потому что до сегодняшнего дня об этой штуке знало человек 10 =) Ну так начало положено.
И, кстати, если относить к «поддерживаемым» только CMS, работающие на одном из популярных фреймворков, выбор, на самом деле, будет очень узким, может 15 продуктов, если говорить о PHP. И любой из них и по количеству пользователей, и по количеству контрибьюторов, и по обильности инфраструктуры, очень далеко отстает от наиболее популярных CMS, написанных безо всякого фреймворка (ну или утверждающих, что «мы сами себе фреймворк»). Поправьте, если неправ.
Спасибо за интерес. Машинку надо уметь выбрать и настроить, для аудитории сайтбилдеров это, все-таки, довольно сложная задача.
Кроме того, как вокруг сервиса, так и вокруг отчуждаемой «коробки» можно строить инфраструктуру платных тем и дополнений. Многие зарубежные открытые цмски тем и живут.
Хм, должен грузиться с Google Fonts. И Fira Sans, который для сайта, и Roboto, который для админских интерфейсов. Пришлите, пожалуйста, ссылку на вашу демо-копию в ЛС, проверю.
Указывать семейство — да, хорошая практика, поправим, спасибо.
Не с нуля, там интереснее все было. Изначально план состоял в том, чтобы «чуть-чуть допилить одну известную CMS». Как альтернативный сценарий рассматривали пересадку на Yii, но с той диспозиции оно казалось неоправданной авантюрой. Кто же знал, что в процессе рефакторинга (и, прости Господи, пивотов) от «одной известной CMS» не останется практически ничего.
Я предполагал, что Гитхаб найдут, но не думал, что в первом же комментарии =) Не хотели его светить прямо сейчас по двум причинам: во-первых, на данный момент очень очень хочется получить фидбэк именно по интерфейсным решениям, во-вторых там надо приводить в порядок демо-сайт — он отличается от того, что сейчас можно собрать в качестве демки на floxim.ru и сильно отстал в развитии.
Про код и вообще внутренности будет отдельный пост, и, надеюсь, не один.
Костя (мл. партнер): Паш, а мы все про**ли? Паша (ст. партнер): Нет, 90 тысяч осталось. Костя: Долларов? Паша: Рублей. Костя: А сколько новый кайен стоит, не помнишь? Паша: 90 тысяч. Костя: Рублей? Паша: Долларов. Костя: А… жалко, и ну его. А помнишь Олю, ну, бухгалтершу, что-то нам консультировала? Паша: Да, премилая барышня, и очень неудобно… Костя: Мы ей сколько должны? Паша: 50 тысяч. Костя: Долларов? Паша: Рублей. Костя: Во! Это хорошо. Давай вернем, а? Паша: Конечно, тем более что очень неудобно… Костя: Ну а то у нее мордашка симпатичная, да? Паша: Да, премилая барышня, и… Костя: А я бы ее в кино позвал, или там… а так неудобно как-то, с этим долгом… Паша: Да, очень неудобно вышло! Костя: Ну, заметано!
4 июля, Москва. Звонит телефон:
Паша: Але? Знакомый 1: Здравствуйте, Павел Павлович! Мы тут один проект начинаем… Паша: А вы кто? Знакомый 1: Ну, вы помните Ольгу Запырину, консультанта по финансам… Паша: Да, премилая барышня… Знакомый 1: А вы могли бы ее рекомендовать в наш проект на роль… Паша: Мог бы. А вы кто? Знакомый 1: Спасибо! Пока я ждал заказ из «Утконоса» (быстро доставили, очень удобно), я как раз подумал, что она обладает нужными для вашего бизнеса связями… Паша: Возможно, а вы… Знакомый 1: Ну, до свиданья!
5 июля, Москва. Звонит телефон:
Паша: Але? Знакомый 2: Здравствуйте, Павел Павлович! Мой знакомый из «Утконоса» ищет консультанта по финансам, вы можете что-нибудь сказать об… Паша: Ольге Запыриной? Да, премилая барышня! А вы, простите, к… Знакомый 2:… а я как знал, и ведь такие у нее связи, самое то для вашего бизнеса! Спасибо, до свиданья.
6 июля, Москва, офис Pavel & Konstantin Partners:
Оля: Привет, мальчики, как отдохнули? Кучу денег небось потратили… Паша: Ольга Валерьевна, если вы о деньгах, то мы… Костя: Оль, прости, это секретарша накосячила, мы ее того, сейчас все вернем… Оля: Ой, Костя, ты такой мачо! Так загорел! Такой молодой! Давай проект мутить! Паша: «Того» в смысле уволили! И очень неудобно… Оля: Павел Павлович, а вы почему не загорели? И к тому же лысеете, кажется… Давайте про долг говорить. Паша: Хм, не знаю… так про долг… конечно… вам наличными удобнее, или на карточку? Оля: [молчит] Костя: Оль, можно вебманями… или налом? Оля: [молчит] Паша: Наличными есть половина, Ольга Валерьевна, скажите, куда остаток перевести? Оля: [молчит, чего бы ей ни стоило] Паша: Вот, 25 тысяч рублей, мы вечером снимем еще, приходите. Костя: А потом в кино! Оля: [забирает деньги, уходит]
Паша: Костя, а что это, ***, было? Костя: Переговоры, сэр!
Из дурацких примеров — у меня на бложике в колонке висит вот такой блок:
Живые люди туда активно кликают, потому что интересно :) Клики считаю Метрикой.
Из серьезных способов применения данных о запросе стоит отметить:
— отображение более релевантных записей в блоке «См. также» (для товаров, новостей и т.д.)
— ранжирование списков с учетом запроса (если юзер попал на страницу категории, при этом искал конкретный товар — показать его сверху)
— кластеризация запросов и анализ эффективности по группам, возможно в сочетании с типами страниц (отказы, конверсии)
— адаптация страницы под уточняющие слова запроса (например, страница Мадонны на муз. портале содержит блоки «биография», «фото», «видео», если юзер искал «Мадонна видео», выводим соответствующий блок наверх).
Во всех этих случаях важно уметь сопоставить запрос и сессию. Во всех случаях юзеру, кажется, ничего не угрожает, при этом он видит более релевантный результат, что повышает лояльность к поисковику. Более того, во всех случаях юзеру совсем не обязательно явно сообщать, что его мы знаем его запрос (это как раз многих раздражает).
Таким образом, благопристойные причины отдавать реферер владельцу сайта, мне кажется, есть. Нежелание Яндекса делиться этими данными со вражескими счетчиками, социалками и чужими рекламными сетями — тоже понятно. Мне кажется, было бы разумным шагом давать вебмастеру ключ для расшифровки, опять же в качестве эксперимента. Или даже API с привязкой к IP, чтобы этот ключ не вбивали в настройки лирушного счетчика. Ну и посмотреть, будут ли пользоваться, а если будут — во благо ли, или во зло :)
Андрей, а можно развить пример с богатенькой невестой-бренд-менеджером-велосипедисткой, и показать, как ее портрет влияет (в итеративном режиме) на прочие разделы документа? =) Моей фантазии хватает только на корректировку стилистики промо-материалов. Есть другие способы применения этой информации?
По поводу цифры в 20% на мобильные OS: все-таки надо иметь ввиду, что li.ru считает большие соц. сети рунета (Вконтакте, Одноклассники, МойМир). Если взять срез, отбрасывающий посещения этих сайтов (хотя бы частично), цифра значительно уменьшится. Например:
Ну так чем она сложнее, тем актуальнее то, о чем я говорю. Если на сайте много разношерстных лейаутов, умножение их на «экраны» (т.е. наборы одновременно отображаемых блоков) может привести к анархии.
В нашей CMS это будет выглядеть так:
:) Это все, что тут требуется от шаблона. Дальше все делается мышкой, порядок такой:
Итого: блоки стоят где надо, в нужном порядке, без правки шаблона. Пункты 1 и 2 можно объединить в один блок, зависит от реализации крутилки (надо ли настраивать место показа на уровне отдельного банера).
Я не очень понял, как добывать акции. Я сегодня слишком мало спал, чтобы прямо сейчас расшифровать этот
чем-то похожий на perlлаконичный и понятный синтаксис. Вот этот [*actionsids*] — его значение откуда берется? Оно какого типа?Как вариант, если считать, что акции лежат где-то отдельно (например, в разделе «Новости»):
Можно даже сделать, чтобы у акции было несколько категорий. Примерно так же, только кликов больше =) Трюк со значением «текущая страница» в условии не пройдет, если мы хотим показывать блок не только на самой странице категории, но и внутри нее (например, на странице товара). Но про такой кейс мы помним и, как только будет, на чем наглядно показать, мы его реализуем, добавив во вторую выпадушку варианты «ближайший предок, имеющий тип...» + выбор типа, и «предок N-го уровня (название)», собственно, находящий нужный элемент сверху вниз по хлебным крошкам. (Я начинаю понимать, почему начальство меня часто спрашивает, точно ли у нас не получится что-то типа друпала, снова эта картинка).
Кстати, а в ModX этот сценарий разруливается?
Ну так вы же не спорите =) я это и написал — такой подход проще, ибо очевиднее. Вопрос только в цене.
Значит вы мало сил уделяете воспитательной работе. Открою секрет, большинство клиентов (как минимум в Мск.) готовы не задумываясь отдать за хостинг сумму где-то между топовым VPS и дохленьким дедиком, лишь бы работало. Если есть знакомые из веб-студий — поспрашивайте, кто почем продает хостинг, очень удивитесь.
Посчитал, 900кб в архиве, 3мб если распаковать. Ну и там еще есть что почистить.
Напишу непременно, ок ;)
Это у вас чанки — не шаблоны, а по сути вполне шаблоны, называются просто иначе.
Куча открывающих тегов не при вызове, а в коде самого шаблона (ок, чанка :)). Если вызов выглядит так:
То в коде pagehead будет что-то типа:
А в pagefoot соответственно так:
ok, пример немного утрированный, всякие оформительские врапперы появляются не везде. Но появляются.
Это вам кажется, что вы решаете проблему различия верстки. На самом деле это другая проблема — различия набора данных. Верстка-то одна, хидер-контент-сайдбар-футер. Отличия в том, какие блоки показываются в «дырке» под названием «контент» и в том, показывается ли сайдбар. Это одна и та же верстка, которая немного меняется в зависимости от пришедшего набора данных. Ваш подход приведет к тому, что для всех типов страниц, где есть сайдбар, придется копипасить вот это:
У нас же оно существует в единственном экземпляре и разруливается добавлением довольно простой логики:
Всего две проверки (или одна, если div.ws нужен не только при наличии сайдбара). Но мы больше нигде не размножаем этот код, он у нас целиком под контролем. Если завтра дизайнер нарисует нечто такое, что не реализуешь без пяти врапперов, мы добавим их в одном единственном месте, а не будем бегать по шаблонам.
А у нас в шаблоне вообще не бывает никакой логики показа чего-либо, кроме генерируемой шаблоном разметки :) Это не дело шаблона, решать, что показывать. Это другой слой. У нас. Я понимаю, почему у ModX (и у многих других) по-другому, подход с «активным типизированным шаблоном» проще и очевиднее, но офигительно проигрывает в гибкости.
Не буду спорить. Я сам не брезгую «быстрыми грязными решениями», и вообще «наговнокодить по-быстрому» — это очень ценное для бизнеса умение :) Просто надо понимать, что такие решения — именно «грязные». При этом нормальные платформы стараются сокращать оверхед на организацию всего по феншую (генераторы + соглашения), и цена того, чтобы сделать все сразу как надо, на самом деле, не очень велика, особенно когда выработана соответствующая привычка.
Ох, ну нет же =) То, что я описал — это «декомпозиция для чайников» :)
Я таких очень давно не видел, но знаю, что они есть. Кстати, именно по этой причине мы стараемся до последнего не расширять стек используемых технологий, и, в частности, не пускаем в проект ноду ни в каком виде :) Кому надо — приделают, но из коробки оно работает с минифайером и компайлером less, написанными на голом PHP, соответственно, на шареде тоже заведется.
Безусловно. Настолько разные, что у нас долгое время было два режима: «Редактирование» для правки контента и «Дизайн» для добавления/настройки блоков. Мы их в итоге объединили, потому что собственно контент тоже может состоять из блоков (например, если нужно собрать лонг-рид из множества этажей, с каверами, врезками, галереями и т.д.). А режим «Дизайн» люди не видели и не понимали. Поэтому сейчас все контролы доступны в «Редактировании». Но мы планируем все-таки решить задачу их разделения, через систему прав — «крутой» пользователь может добавлять любые блоки куда угодно, а «редактор» — только на созданные им страницы в ограниченный набор областей, примерно так.
Мы тоже так считаем. Но на практике, когда даешь пользователю выбирать, дизайнеру и верстальщику приходится решать много очень тонких и интересных задачек, продумывая, как тот или иной шаблон будет вести себя в разных окружениях. Нам в этом очень помогает БЭМ-методология, но даже ее кунг-фу местами не хватает. Например, когда друг в друга оказываются вложены одноименные блоки (набор колонок, вставленный в другую колонку), или когда внешний вид элемента зависит от контекста, куда помещен блок (текст шрифта меню должен быть белым, если меню стоит в шапке, или черным, если меню попало куда-то еще). Пока такие задачки решаются не очень системно. Планирую грузануть ребят из Яндекса, когда наберется достаточно подобных головоломок =)
Ну вот последняя собранная версия — 5мб в архиве, вместе с демо-сайтом (который включает штук 40 больших картинок).
Если не считать правку шаблона кодингом, у нас можно «без кодинга вообще» сделать очень много всего :) Но все-таки правка шаблона — это кодинг.
Смотрите, поскольку прямо сейчас я не могу показать код и инструменты разработчика, это не очень предметный разговор. Давайте, если вам интересно, вы придумаете какой-нибудь заковыристый кейс, а когда мы выпустим полноценный релиз в паблик — я его обязательно разберу в подробностях.
Я могу только сказать, что у нас логика шаблонов структурна и прозрачна =) См. выше — следите за новостями, в обозримом будущем все покажем. QuadBraces видел, да. Идея интересная. Я сам думал над тем, чтобы сделать наш шаблонизатор целиком отчуждаемым, но сейчас он много где завязан на наши модели из-за необходимости делать прозрачный edit-in-place, и вынесение этого слоя куда-то в наружу — довольно тонкая хирургическая операция.
Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика. Шаблон, состоящий из 10 открывающих тегов — это плохо. Если хидер-футер есть везде и всегда идут парой — это один шаблон. А контент вообще не должен зависеть от шаблона, контент — это то, что приходит снаружи. Если «шаблон» — это обвязка + вызовы какого-то исполняемого кода, то это не шаблон, а «экран», «тип страницы» или еще как-то. В этом случае понятно, почему у вас их получается «порядка десятка разных». У нас это именно шаблон, данные в который приходят снаружи (и настраиваются путем добавления блоков в нужные области). Если совсем упростить, то так:
Это не совсем настоящий код — обработка лейаута происходит глубоко внутри, и явно вызывать его шаблон не нужно, а вместо переменных в лейауте используются области для расстановки блоков. Но принцип именно такой: шаблон хранит разметку, в которой есть точки, позволяющие вывести данные, пришедшие снаружи. А не вызовы кода, который сам добывает данные.
Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак :) Есть немало людей, которые к этому еще и пачку тестов напишут. И будут по-своему правы. Если есть стопроцентное понимание, что этот код одноразовый, его можно писать как угодно. Но практика показывает, что одноразовый код, во-первых, тоже имеет свойство ломаться, и если он написан «как попало», заметить и починить поломку будет сложнее. Во-вторых, одноразовый код иногда внезапно оказывается нужен где-то еще с немного другими параметрами, и тогда тоже начинаются приключения.
Обычно под повторным использованием подразумевается немного другое — когда для реализации отличий в поведении не нужно копипастить код целиком и править нужное место, а достаточно передать необходимые параметры.
Хранить много экземпляров не обязательно. Во-первых, система поддерживает мультисайтовость. Если сайты похожи и управлять ими должны примерно одни и те же люди — просто заводим все на одной копии. Если сайты сильно отличаются, можно цеплять ядро системы и модули при помощи симлинков, это будет работать. Собственно, демка, которую мы тут показываем, именно так и работает — причем у нас остается техническая возможность управлять подключенными модулями для каждого сайта отдельно.
Но вообще такой подход имеет много недостатков, и без крайней надобности лучше им не пользоваться. Ядро системы и модули подключаются через Composer, и это дает гораздо больше гибкости и предсказуемости. А экономить на диске имеет смысл, когда речь идет о тысячах сайтов. Для десятков даже на дохлой VPS экономия будет не особо заметной.
Нет, не уверены. Как можно быть в чем-то уверенным, когда речь за ослика? =)
Если серьезно, тут не должно возникать особых проблем. Поля типа «строка» жестко фильтруются от любого HTML, а поля «rich text» обрабатывает сторонний редактор (собственно, Redactor от Imperavi, мы купили OEM-лицензию). Он состоит из почти 10к строк кода, многие из которых содержат слово «msie», и можно надеяться, что наиболее вырвиглазные косяки они обрабатывают.
К нашей компании есть смысл обращаться, если пользователь использует, например, стандартный шаблон, разработанный нами. Он может предложить улучшение. В остальных случаях ему следует обращаться куда-нибудь еще, потому что мы сами разработкой сайтов не занимаемся (ну, точнее, занимаемся, потому что нужны подопытные кролики, но не массово — в основном для знакомых). Но вообще сейчас рано об этом говорить и гадать на тему легкости кастомизации. Следите за новостями, сделаем полноценный запуск — сможете сами оценить =)
Не понимаю, о чем речь. Простой каталог и анкетирование приходится говнокодить независимо от платформы. Просто у платформ с историей это уже сделали (ну, не святой же дух зачал все эти друпал-модули?). А у нас все впереди.
Я говорил о другом. Если у вас уже есть что-то работающее, и вам понадобилось к нему новое поле, создать поле можно в браузере, а обработку придется добавлять в код. Собственно, в Modx оно так же устроено, можно добавить TV, но она не начнет магическим образом показываться на сайте где нужно и использоваться как нужно, пока это не будет описано в коде.
А я что пишу? Добавляем поле к компоненту (у вас это ресурс), и оно начинает отображаться в форме, сохраняться в БД, и, если вывести в шаблон — отображаться. Я ровно это и написал: чтобы вывести в шаблон, нужно править код шаблона. Код моделей/контроллеров надо править, если поле требует какой-то особой логики (правила валидации в модели, экшн для вывода с фильтрацией/группировкой по этому полю в контроллере и т.д.).
Кстати, новое поле без единой строчки кода будет доступно в настройках блока: во-первых, по нему можно будет сортировать списки (если тип позволяет), во-вторых — использовать поле в фильтрах блока-выборки (то есть можно сделать блок, в котором покажутся объекты, у которых значение поля больше-меньше-равно-содержит и.т.д. указанное значение).
Evolution изучу, спасибо.
А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД… =)
С написанием шаблонов под Джумлу нет ничего общего, но для неподготовленных и слабых духом оно может оказаться и пострашнее: контекст исполнения, мэтчинг шаблонов по предикатам… Я, знаете ли, пол жизни на XSLT писал, такое даром не проходит… )
У нас есть довольно мощный набор инструментов для повторного использования кода. Повторно использовать код можно не только при помощи чанков, если что ;)
Есть два «грязных» типа блока — «произвольный HTML» и «PHP+FloxML». Задумывались примерно для таких вещей, но пока не считаются «честными» решениями. Во-первых, это хранение кода в БД, см. выше. Во-вторых, пугало для пользователя.
«Целый модуль» — звучит угрожающе, но по сути там все то же самое. PHP-код, достающий данные, и код шаблона, их показывающий. Если никуда не спешить, можно PHP-код разделить на модель+контроллер, а если очень спешить — можно засунуть получение данных прямо в шаблон (curl жирновато, но дернуть file_get_contents('http://...') пока можно, выражения не фильтруются). Суть та же.
Ну и кавычки-ёлочки, и mdash тоже. Одна (временная) проблема, пока не успели прикрутить к формам, работает только при иплейсном редактировании.
Использован типограф Дениса Селезнева github.com/typograf/typograf Для работы в realtime его пришлось пропатчить, сделав компиляцию регулярок одноразовой и изменив несколько правил, которые давали неожиданный результат на границе текста (типограф изначально рассчитан на ситуацию «текст уже написан, теперь мы его типографируем», а тут надо типографить прямо в процессе набора).
Как только найдется время осмыслить, как эти изменения могут повлиять на штатную работу, обязательно оформим pull request.
У нас пока нет достаточной статистики, чтобы утверждать, что система понятна обычному веб-программисту. Но есть все предпосылки надеяться, что так и будет. Жизнь покажет, следите за новостями =) Пока мы только хотели показать пользовательский интерфейс, посмотреть, как люди будут на него реагировать. Кстати, спасибо Хабру, данных для анализа набралось немало.
API, разумеется, есть. Документировать его пытались непосредственно в коде. Замахнулись на мировое господство и стали писать сразу на английском языке. Некоторое время спустя результат пришлось почти целиком выпилить, поскольку уровень английского в среднем по команде не дотягивал до презентабельного. Мы решим эту проблему. И мануалы напишем, уже есть черновики для внутреннего использования.
Можно создавать свои модули и темы. Система реализует следующие сценарии расширения:
— добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);
— добавление полей к существующим типам и их обработка (пример: добавить всем страницам поле, отвечающее за og:image и вывести его);
— изменение поведения существующих компонентов через систему событий (при удалении или изменении элементов указанного типа отправлять на почту админу предыдущее состояние элемента);
— изменение поведения контролов системы на клиенте через JS API (типограф, который можно наблюдать в демке — самостоятельный модуль);
— добавление новых шаблонов для существующих блоков;
— кастомный роутинг для динамики.
Собственно, на данный момент создание модуля — единственный способ что-то напрограммировать: у нас нету того, что обычно называется «Application», вместо этого создается модуль «App» вендора «My», куда складываются специфичные для проекта штуки.
Посмотрите внимательно на наш WYSIWYG =) Он — не совсем то, что обычно понимают под этим набором букв. Традиционно, «визивиг» условно эквивалентен понятию «rich text editor», но если вслушаться в расшифровку, станет ясно, что это не инструмент, а принцип. Причем, что самое забавное, очень часто традиционные WYSIWYG-редакторы этот принцип нарушают: если разработчик серией специальных магических пассов не подтянул в редактор нужные CSS, пользователь будет «see» в редакторе не совсем то, что он «get» на выходе :)
Так вот, мусорная разметка обычно появляется в двух случаях:
1. Ее создает rich text editor, когда пользователь пытается нащелкать в окошке TinyMCE какую-то сложную конструкцию;
2. Ее создает слой сайт-конструктора, когда пользователь мышкой двигает блок по холсту и крутит паддинги-маргины.
Оба случая возникают из-за плохой декомпозиции данных. Вместо внесения данных пользователь занимается «накликиванием дизайна», вместо управления контентом — управлением «кусками HTML». В нашей парадигме такого происходить не должно: данные разбиваются на поля при создании компонента, их отображение продумывает дизайнер и верстает верстальщик. Пользователю остается только выбрать подходящий вариант оформления исходя из бизнесовых задач, исходя из важности и устройства контента. Конечно, для этого тоже требуется некоторый вкус и чутье, но это значительно проще, чем когда приходится «фотошопить в браузере».
Что касается непосредственно текстового редактора: мы реализовали управление набором его кнопок и слегка «проредили» дефолтный набор. Может выкинем еще парочку =)
Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов. Хотя есть варианты, как выводить поля без участия программиста. Пока остается открытым вопрос, найдется ли достаточное количество кейсов для этой задачи. Потому что UI рискует получится «не очень прозрачным» [тут должна быть картинка, которая находится по запросу «drupal learning curve»] ;)
Так и должно быть, так и у нас. Единственный нюанс — для типовых проектов наемного разработчика в этой модели может заменить разработчик, собравший типовое решение (модуль, тему или целый готовый сайт).
Честно сказать, я не очень понимаю, каким местом джумла ориентирована «исключительно на пользователя», зато хорошо понимаю ваши эмоции =) В бытность фрилансером сам пару раз сталкивался (хотя давно это было). Ориентированность на пользователя — это уж скорее про Wordpress, считается, что он завоевал популярность благодаря своей понятности и доступности. Которых, впрочем, ему изначально было проще добиться из-за узкой специализации.
Про Evolution не помню, а Revo ковырял довольно плотно. И к нему у меня есть претензии, хотя озвучивать их прямо здесь, наверное, не стоит. Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной, хотя соблазн их размножить — был :)
Их не так уж много. Самое разнообразие — контролы отдельных полей:
— datepicker
— управление картинкой
— панелька с кнопками wysiwyg
— выбор связанной сущности для полей-связей (мы его называем livesearch)
— текстовый инпут, если значение поля попадает в атрибут (например, адреса для произвольных ссылок)
Контролы сущности конечны и немногочисленны:
— редактировать (открывает форму)
— удалить
— скрыть/показать
— перетащить (если доступна ручная сортировка)
Контролов блока еще меньше:
— настроить
— удалить
— перетащить
Некоторая печаль происходит, когда все это добро группируется на одной ноде (блок, состоящий из одного элемента, всю площадь которого занимает одно поле, например картинка). В этом случае весь зоопарк нужно уместить в одной панельке.
Самый самый первый вариант интерфейса как раз помещал все кнопки в одну фиксированную плашку в верхней части экрана. Причем мы к такому варианту даже возвращались. Но так теряется ощущение контекста, к тому же приходится делать много движений мышью.
Нынешняя контекстная панелька появляется сразу над выделенным элементом и прижимается к левому краю, это сравнительно предсказуемое и интуитивно ожидаемое поведение. Неожиданное случается, если верхний-левый угол занят. Например, элемент большой по высоте и его верхушка уходит за верхний край экрана, панелька уйдет вниз при наличии там свободного места, либо прилипнет к верхней части экрана, пока место не появится. Подумаем, как проработать этот момент.
Мы выделили два основных сценария. Для создания «чего-то большого» с нуля — формы, т.к. их проще линейно заполнять и сложнее что-то пропустить. Для быстрых правок «на лету» и для добавления «чего-то не слишком большого» (типа текста-с-картинкой, телефона, отдельной фотки) — визивиг.
Кроме того, визивиг позволяет вообще не решать два извечных вопроса:
1) вот эта хреновинка — это которое поле формы?
2) вот это поле формы — это что за хреновинка? =)
Это они у нас еще не до конца «поженились» )) Сейчас при работе с панелью изменения показываются, но тут же перейти к инплейсному редактированию нельзя. Мы склонны считать, что это скорее бага =)
Да, изменения отображаются и сейчас, но иногда сам редактируемый узел оказывается под формой-панелью, и его тупо не видно. Мы много думаем над решением этой проблемы. Очевидный вариант — закатать все в ифреймы и не перекрывать контентную часть, а сжимать ее — но при этом теряется pixel perfect. Не очень большая беда, но все-таки. Два других варианта — приделать к панельке контрол, позволяющий ее быстро прятать/показывать/сужать (примерно как у wix), либо показывать ее слева или справа в зависимости от того, где расположен редактируемый узел (снижает предсказуемость, не работает для узлов, занимающих всю ширину).
Даже без визивига есть ограничения — элемент нужно элементарно выбрать и сделать, чтобы он никуда не убегал (привет, слайдер! =)). Чтобы показать кнопку редактирования. Без этого можно обойтись, если дублировать где-то в слое админки все элементы в табличном виде, эдакая админка-в-панельке. Но это, опять же, уводит нас от контекста, плюс возникают проблемы с редактированием данных, попавших на страницу через разнообразные выборки-зеркала (последние новости, лучшие комментарии и т.д.).
То есть сделать условно-контекстную админку с табличными списками — можно, и наверное нужно, иногда работа с данными в таком виде гораздо удобнее. Но не как единственный-основной способ получения доступа к контенту.
P.S. Долго пытался вспомнить, где же я видел человека в шлеме. Вспомнил: вот здесь! Ах, милая я.рушка… Почти восемь лет, однако =)
P.P.S. Еще раз спасибо за комментарий по существу. Надеюсь, по размеру моего ответа остальные хабражители поймут, насколько сильно мы хотим поговорить о нашем интерфейсе, и тоже что-нибудь про него расскажут или спросят =)
Поддерживаемость зависит от коммьюнити гораздо больше, чем от технологического стека, и тут нам пока, действительно, хвастаться нечем, потому что до сегодняшнего дня об этой штуке знало человек 10 =) Ну так начало положено.
И, кстати, если относить к «поддерживаемым» только CMS, работающие на одном из популярных фреймворков, выбор, на самом деле, будет очень узким, может 15 продуктов, если говорить о PHP. И любой из них и по количеству пользователей, и по количеству контрибьюторов, и по обильности инфраструктуры, очень далеко отстает от наиболее популярных CMS, написанных безо всякого фреймворка (ну или утверждающих, что «мы сами себе фреймворк»). Поправьте, если неправ.
Кроме того, как вокруг сервиса, так и вокруг отчуждаемой «коробки» можно строить инфраструктуру платных тем и дополнений. Многие зарубежные открытые цмски тем и живут.
Указывать семейство — да, хорошая практика, поправим, спасибо.
Не с нуля, там интереснее все было. Изначально план состоял в том, чтобы «чуть-чуть допилить одну известную CMS». Как альтернативный сценарий рассматривали пересадку на Yii, но с той диспозиции оно казалось неоправданной авантюрой. Кто же знал, что в процессе рефакторинга (и, прости Господи, пивотов) от «одной известной CMS» не останется практически ничего.
Я предполагал, что Гитхаб найдут, но не думал, что в первом же комментарии =) Не хотели его светить прямо сейчас по двум причинам: во-первых, на данный момент очень очень хочется получить фидбэк именно по интерфейсным решениям, во-вторых там надо приводить в порядок демо-сайт — он отличается от того, что сейчас можно собрать в качестве демки на floxim.ru и сильно отстал в развитии.
Про код и вообще внутренности будет отдельный пост, и, надеюсь, не один.
Костя (мл. партнер): Паш, а мы все про**ли?
Паша (ст. партнер): Нет, 90 тысяч осталось.
Костя: Долларов?
Паша: Рублей.
Костя: А сколько новый кайен стоит, не помнишь?
Паша: 90 тысяч.
Костя: Рублей?
Паша: Долларов.
Костя: А… жалко, и ну его. А помнишь Олю, ну, бухгалтершу, что-то нам консультировала?
Паша: Да, премилая барышня, и очень неудобно…
Костя: Мы ей сколько должны?
Паша: 50 тысяч.
Костя: Долларов?
Паша: Рублей.
Костя: Во! Это хорошо. Давай вернем, а?
Паша: Конечно, тем более что очень неудобно…
Костя: Ну а то у нее мордашка симпатичная, да?
Паша: Да, премилая барышня, и…
Костя: А я бы ее в кино позвал, или там… а так неудобно как-то, с этим долгом…
Паша: Да, очень неудобно вышло!
Костя: Ну, заметано!
4 июля, Москва. Звонит телефон:
Паша: Але?
Знакомый 1: Здравствуйте, Павел Павлович! Мы тут один проект начинаем…
Паша: А вы кто?
Знакомый 1: Ну, вы помните Ольгу Запырину, консультанта по финансам…
Паша: Да, премилая барышня…
Знакомый 1: А вы могли бы ее рекомендовать в наш проект на роль…
Паша: Мог бы. А вы кто?
Знакомый 1: Спасибо! Пока я ждал заказ из «Утконоса» (быстро доставили, очень удобно), я как раз подумал, что она обладает нужными для вашего бизнеса связями…
Паша: Возможно, а вы…
Знакомый 1: Ну, до свиданья!
5 июля, Москва. Звонит телефон:
Паша: Але?
Знакомый 2: Здравствуйте, Павел Павлович! Мой знакомый из «Утконоса» ищет консультанта по финансам, вы можете что-нибудь сказать об…
Паша: Ольге Запыриной? Да, премилая барышня! А вы, простите, к…
Знакомый 2:… а я как знал, и ведь такие у нее связи, самое то для вашего бизнеса! Спасибо, до свиданья.
6 июля, Москва, офис Pavel & Konstantin Partners:
Оля: Привет, мальчики, как отдохнули? Кучу денег небось потратили…
Паша: Ольга Валерьевна, если вы о деньгах, то мы…
Костя: Оль, прости, это секретарша накосячила, мы ее того, сейчас все вернем…
Оля: Ой, Костя, ты такой мачо! Так загорел! Такой молодой! Давай проект мутить!
Паша: «Того» в смысле уволили! И очень неудобно…
Оля: Павел Павлович, а вы почему не загорели? И к тому же лысеете, кажется… Давайте про долг говорить.
Паша: Хм, не знаю… так про долг… конечно… вам наличными удобнее, или на карточку?
Оля: [молчит]
Костя: Оль, можно вебманями… или налом?
Оля: [молчит]
Паша: Наличными есть половина, Ольга Валерьевна, скажите, куда остаток перевести?
Оля: [молчит, чего бы ей ни стоило]
Паша: Вот, 25 тысяч рублей, мы вечером снимем еще, приходите.
Костя: А потом в кино!
Оля: [забирает деньги, уходит]
Паша: Костя, а что это, ***, было?
Костя: Переговоры, сэр!
Живые люди туда активно кликают, потому что интересно :) Клики считаю Метрикой.
Из серьезных способов применения данных о запросе стоит отметить:
— отображение более релевантных записей в блоке «См. также» (для товаров, новостей и т.д.)
— ранжирование списков с учетом запроса (если юзер попал на страницу категории, при этом искал конкретный товар — показать его сверху)
— кластеризация запросов и анализ эффективности по группам, возможно в сочетании с типами страниц (отказы, конверсии)
— адаптация страницы под уточняющие слова запроса (например, страница Мадонны на муз. портале содержит блоки «биография», «фото», «видео», если юзер искал «Мадонна видео», выводим соответствующий блок наверх).
Во всех этих случаях важно уметь сопоставить запрос и сессию. Во всех случаях юзеру, кажется, ничего не угрожает, при этом он видит более релевантный результат, что повышает лояльность к поисковику. Более того, во всех случаях юзеру совсем не обязательно явно сообщать, что его мы знаем его запрос (это как раз многих раздражает).
Таким образом, благопристойные причины отдавать реферер владельцу сайта, мне кажется, есть. Нежелание Яндекса делиться этими данными со вражескими счетчиками, социалками и чужими рекламными сетями — тоже понятно. Мне кажется, было бы разумным шагом давать вебмастеру ключ для расшифровки, опять же в качестве эксперимента. Или даже API с привязкой к IP, чтобы этот ключ не вбивали в настройки лирушного счетчика. Ну и посмотреть, будут ли пользоваться, а если будут — во благо ли, или во зло :)
Переходы с Яндекса — 6.2%
Переходы с Google — 12%
Категория «Товары и услуги» — 7.9%
Однако, во всех случаях рост очень быстрый. Исследование ценное, надеюсь, поможет кому-нибудь не проспать «будущее здесь» =)
Месяцем промахнулись =)