Comments 43
А вы прямо все с нуля писали, без использования фреймворков, судя по гитхабу? )
Привет!
Не с нуля, там интереснее все было. Изначально план состоял в том, чтобы «чуть-чуть допилить одну известную CMS». Как альтернативный сценарий рассматривали пересадку на Yii, но с той диспозиции оно казалось неоправданной авантюрой. Кто же знал, что в процессе рефакторинга (и, прости Господи, пивотов) от «одной известной CMS» не останется практически ничего.
Я предполагал, что Гитхаб найдут, но не думал, что в первом же комментарии =) Не хотели его светить прямо сейчас по двум причинам: во-первых, на данный момент очень очень хочется получить фидбэк именно по интерфейсным решениям, во-вторых там надо приводить в порядок демо-сайт — он отличается от того, что сейчас можно собрать в качестве демки на floxim.ru и сильно отстал в развитии.
Про код и вообще внутренности будет отдельный пост, и, надеюсь, не один.
Не с нуля, там интереснее все было. Изначально план состоял в том, чтобы «чуть-чуть допилить одну известную CMS». Как альтернативный сценарий рассматривали пересадку на Yii, но с той диспозиции оно казалось неоправданной авантюрой. Кто же знал, что в процессе рефакторинга (и, прости Господи, пивотов) от «одной известной CMS» не останется практически ничего.
Я предполагал, что Гитхаб найдут, но не думал, что в первом же комментарии =) Не хотели его светить прямо сейчас по двум причинам: во-первых, на данный момент очень очень хочется получить фидбэк именно по интерфейсным решениям, во-вторых там надо приводить в порядок демо-сайт — он отличается от того, что сейчас можно собрать в качестве демки на floxim.ru и сильно отстал в развитии.
Про код и вообще внутренности будет отдельный пост, и, надеюсь, не один.
Ну, тут вопрос в том что я в первую очередь ищу на чем оно написано. В этом случае — нашел исходники, понял, что даже шаблонизатор по сути свой, записал проект в разряд «неподдерживаемые» (тот же Yii уже было бы неплохо), закрыл.
Дело не в том как хороша ваша CMS, дело в том как сложно ее поддерживать через год.
Дело не в том как хороша ваша CMS, дело в том как сложно ее поддерживать через год.
Шаблонизатор тут не может быть никаким другим, это специфика нашего подхода к редактированию: нужно протащить через шаблон всю необходимую мета-информацию, причем не добавляя в результирующий HTML лишних узлов и не заставляя кодера писать все мета-данные руками.
Поддерживаемость зависит от коммьюнити гораздо больше, чем от технологического стека, и тут нам пока, действительно, хвастаться нечем, потому что до сегодняшнего дня об этой штуке знало человек 10 =) Ну так начало положено.
И, кстати, если относить к «поддерживаемым» только CMS, работающие на одном из популярных фреймворков, выбор, на самом деле, будет очень узким, может 15 продуктов, если говорить о PHP. И любой из них и по количеству пользователей, и по количеству контрибьюторов, и по обильности инфраструктуры, очень далеко отстает от наиболее популярных CMS, написанных безо всякого фреймворка (ну или утверждающих, что «мы сами себе фреймворк»). Поправьте, если неправ.
Поддерживаемость зависит от коммьюнити гораздо больше, чем от технологического стека, и тут нам пока, действительно, хвастаться нечем, потому что до сегодняшнего дня об этой штуке знало человек 10 =) Ну так начало положено.
И, кстати, если относить к «поддерживаемым» только CMS, работающие на одном из популярных фреймворков, выбор, на самом деле, будет очень узким, может 15 продуктов, если говорить о PHP. И любой из них и по количеству пользователей, и по количеству контрибьюторов, и по обильности инфраструктуры, очень далеко отстает от наиболее популярных CMS, написанных безо всякого фреймворка (ну или утверждающих, что «мы сами себе фреймворк»). Поправьте, если неправ.
Изначально план состоял в том, чтобы «чуть-чуть допилить одну известную CMS»
Увидев среди контрибуторов знакомый ник, я даже сначала подумал, что знаю, про какую CMS речь :)
Но глянул код — не, совсем не похоже
В линуксе шрифт не подгружается, вы рассчитываете что он есть в системе? в любом случае лучше вместо
использовать
html,
body {
font-family: 'Fira Sans';
}
использовать
html,
body {
font-family: 'Fira Sans', sans-serif;
}
Хм, должен грузиться с Google Fonts. И Fira Sans, который для сайта, и Roboto, который для админских интерфейсов. Пришлите, пожалуйста, ссылку на вашу демо-копию в ЛС, проверю.
Указывать семейство — да, хорошая практика, поправим, спасибо.
Указывать семейство — да, хорошая практика, поправим, спасибо.
Очень рекомендую по поводу Fira Sans посмотреть сюда: stackoverflow.com/questions/27568591/strange-issue-while-google-font-rendering
Косяк очень мерзкий, и имеет место быть (хоть и ловится маленьким процентом пользователей). Я, поймав, искал решение довольно долго.
Косяк очень мерзкий, и имеет место быть (хоть и ловится маленьким процентом пользователей). Я, поймав, искал решение довольно долго.
А что с ценой на вашу CMS планируется? Есть надежда, что будет бесплатный план, чтобы какой-никакой некоммерческий сайт можно было у вас сделать, бросить, и верить, что он будет крутиться?
Сама по себе CMS будет бесплатной, а облачный сервис — скорее всего по модели freemium.
> Сама по себе CMS будет бесплатной,
Просим, просим!
Но вы уверены, что раздавая CMS, вы на облаке заработаете себе на хлеб? Особенно если облако станет стоит в месяц дороже машинки на DigitalOcean?
Просим, просим!
Но вы уверены, что раздавая CMS, вы на облаке заработаете себе на хлеб? Особенно если облако станет стоит в месяц дороже машинки на DigitalOcean?
Риск всегда есть :)
Спасибо за интерес. Машинку надо уметь выбрать и настроить, для аудитории сайтбилдеров это, все-таки, довольно сложная задача.
Кроме того, как вокруг сервиса, так и вокруг отчуждаемой «коробки» можно строить инфраструктуру платных тем и дополнений. Многие зарубежные открытые цмски тем и живут.
Кроме того, как вокруг сервиса, так и вокруг отчуждаемой «коробки» можно строить инфраструктуру платных тем и дополнений. Многие зарубежные открытые цмски тем и живут.
(ошибочный комментарий)
Понравилась идея многослойности для визуализации архитектуры страницы.
fxAnton Немного не поняла у вас таки CMS или конструктор сайтов?
fxAnton Немного не поняла у вас таки CMS или конструктор сайтов?
Вы затронули интересные вопросы. Главный вопрос наверно в том, удачная ли концепция редактирования в принципе. С моей точки зрения визивиг привлекателен на демо-сайтах, чтобы показать «как все просто», но по факту элементы управления разношерстные, находятся все время в разных местах. В перспективе мне кажется, что это тупик и трата лишних ресурсов. И ведь все равно приходится делать «панельки» для редактирования элементов, которых нет в явном виде на странице. Даже не метатеги, а скидки, проценты, сопутствующие товары и т.п. Сочетание визивиг и панели управления с формами расщепляет сознание. А если список заказов, заявок, список пользователей? Все равно нужна панель управления, оторванная от внешнего вида сайта.
Представляется более привлекательной концепция «панель управления со своим стандартным дизайном, где есть все крутилки», но изменения отображаются сразу(на соседней половине страницы, фрейме, соседнем окне) и можно прикинуть как замена заголовка повлияет на вид «предварительного просмотра». При этом фронтенд может быть любой сложности. Но, с другой стороны, у вас есть отличный ответ на вопрос «как быстро найти где это все редактировать».
Представляется более привлекательной концепция «панель управления со своим стандартным дизайном, где есть все крутилки», но изменения отображаются сразу(на соседней половине страницы, фрейме, соседнем окне) и можно прикинуть как замена заголовка повлияет на вид «предварительного просмотра». При этом фронтенд может быть любой сложности. Но, с другой стороны, у вас есть отличный ответ на вопрос «как быстро найти где это все редактировать».
Привет! Спасибо за развернутый комментарий.
Их не так уж много. Самое разнообразие — контролы отдельных полей:
— datepicker
— управление картинкой
— панелька с кнопками wysiwyg
— выбор связанной сущности для полей-связей (мы его называем livesearch)
— текстовый инпут, если значение поля попадает в атрибут (например, адреса для произвольных ссылок)
Контролы сущности конечны и немногочисленны:
— редактировать (открывает форму)
— удалить
— скрыть/показать
— перетащить (если доступна ручная сортировка)
Контролов блока еще меньше:
— настроить
— удалить
— перетащить
Некоторая печаль происходит, когда все это добро группируется на одной ноде (блок, состоящий из одного элемента, всю площадь которого занимает одно поле, например картинка). В этом случае весь зоопарк нужно уместить в одной панельке.
Самый самый первый вариант интерфейса как раз помещал все кнопки в одну фиксированную плашку в верхней части экрана. Причем мы к такому варианту даже возвращались. Но так теряется ощущение контекста, к тому же приходится делать много движений мышью.
Нынешняя контекстная панелька появляется сразу над выделенным элементом и прижимается к левому краю, это сравнительно предсказуемое и интуитивно ожидаемое поведение. Неожиданное случается, если верхний-левый угол занят. Например, элемент большой по высоте и его верхушка уходит за верхний край экрана, панелька уйдет вниз при наличии там свободного места, либо прилипнет к верхней части экрана, пока место не появится. Подумаем, как проработать этот момент.
Мы выделили два основных сценария. Для создания «чего-то большого» с нуля — формы, т.к. их проще линейно заполнять и сложнее что-то пропустить. Для быстрых правок «на лету» и для добавления «чего-то не слишком большого» (типа текста-с-картинкой, телефона, отдельной фотки) — визивиг.
Кроме того, визивиг позволяет вообще не решать два извечных вопроса:
1) вот эта хреновинка — это которое поле формы?
2) вот это поле формы — это что за хреновинка? =)
Это они у нас еще не до конца «поженились» )) Сейчас при работе с панелью изменения показываются, но тут же перейти к инплейсному редактированию нельзя. Мы склонны считать, что это скорее бага =)
Да, изменения отображаются и сейчас, но иногда сам редактируемый узел оказывается под формой-панелью, и его тупо не видно. Мы много думаем над решением этой проблемы. Очевидный вариант — закатать все в ифреймы и не перекрывать контентную часть, а сжимать ее — но при этом теряется pixel perfect. Не очень большая беда, но все-таки. Два других варианта — приделать к панельке контрол, позволяющий ее быстро прятать/показывать/сужать (примерно как у wix), либо показывать ее слева или справа в зависимости от того, где расположен редактируемый узел (снижает предсказуемость, не работает для узлов, занимающих всю ширину).
Даже без визивига есть ограничения — элемент нужно элементарно выбрать и сделать, чтобы он никуда не убегал (привет, слайдер! =)). Чтобы показать кнопку редактирования. Без этого можно обойтись, если дублировать где-то в слое админки все элементы в табличном виде, эдакая админка-в-панельке. Но это, опять же, уводит нас от контекста, плюс возникают проблемы с редактированием данных, попавших на страницу через разнообразные выборки-зеркала (последние новости, лучшие комментарии и т.д.).
То есть сделать условно-контекстную админку с табличными списками — можно, и наверное нужно, иногда работа с данными в таком виде гораздо удобнее. Но не как единственный-основной способ получения доступа к контенту.
P.S. Долго пытался вспомнить, где же я видел человека в шлеме. Вспомнил: вот здесь! Ах, милая я.рушка… Почти восемь лет, однако =)
P.P.S. Еще раз спасибо за комментарий по существу. Надеюсь, по размеру моего ответа остальные хабражители поймут, насколько сильно мы хотим поговорить о нашем интерфейсе, и тоже что-нибудь про него расскажут или спросят =)
но по факту элементы управления разношерстные
Их не так уж много. Самое разнообразие — контролы отдельных полей:
— datepicker
— управление картинкой
— панелька с кнопками wysiwyg
— выбор связанной сущности для полей-связей (мы его называем livesearch)
— текстовый инпут, если значение поля попадает в атрибут (например, адреса для произвольных ссылок)
Контролы сущности конечны и немногочисленны:
— редактировать (открывает форму)
— удалить
— скрыть/показать
— перетащить (если доступна ручная сортировка)
Контролов блока еще меньше:
— настроить
— удалить
— перетащить
Некоторая печаль происходит, когда все это добро группируется на одной ноде (блок, состоящий из одного элемента, всю площадь которого занимает одно поле, например картинка). В этом случае весь зоопарк нужно уместить в одной панельке.
находятся все время в разных местах
Самый самый первый вариант интерфейса как раз помещал все кнопки в одну фиксированную плашку в верхней части экрана. Причем мы к такому варианту даже возвращались. Но так теряется ощущение контекста, к тому же приходится делать много движений мышью.
Нынешняя контекстная панелька появляется сразу над выделенным элементом и прижимается к левому краю, это сравнительно предсказуемое и интуитивно ожидаемое поведение. Неожиданное случается, если верхний-левый угол занят. Например, элемент большой по высоте и его верхушка уходит за верхний край экрана, панелька уйдет вниз при наличии там свободного места, либо прилипнет к верхней части экрана, пока место не появится. Подумаем, как проработать этот момент.
И ведь все равно приходится делать «панельки» для редактирования элементов, которых нет в явном виде на странице. Даже не метатеги, а скидки, проценты, сопутствующие товары и т.п.
Мы выделили два основных сценария. Для создания «чего-то большого» с нуля — формы, т.к. их проще линейно заполнять и сложнее что-то пропустить. Для быстрых правок «на лету» и для добавления «чего-то не слишком большого» (типа текста-с-картинкой, телефона, отдельной фотки) — визивиг.
Кроме того, визивиг позволяет вообще не решать два извечных вопроса:
1) вот эта хреновинка — это которое поле формы?
2) вот это поле формы — это что за хреновинка? =)
Сочетание визивиг и панели управления с формами расщепляет сознание.
Это они у нас еще не до конца «поженились» )) Сейчас при работе с панелью изменения показываются, но тут же перейти к инплейсному редактированию нельзя. Мы склонны считать, что это скорее бага =)
Представляется более привлекательной концепция «панель управления со своим стандартным дизайном, где есть все крутилки», но изменения отображаются сразу(на соседней половине страницы, фрейме, соседнем окне) и можно прикинуть как замена заголовка повлияет на вид «предварительного просмотра».
Да, изменения отображаются и сейчас, но иногда сам редактируемый узел оказывается под формой-панелью, и его тупо не видно. Мы много думаем над решением этой проблемы. Очевидный вариант — закатать все в ифреймы и не перекрывать контентную часть, а сжимать ее — но при этом теряется pixel perfect. Не очень большая беда, но все-таки. Два других варианта — приделать к панельке контрол, позволяющий ее быстро прятать/показывать/сужать (примерно как у wix), либо показывать ее слева или справа в зависимости от того, где расположен редактируемый узел (снижает предсказуемость, не работает для узлов, занимающих всю ширину).
При этом фронтенд может быть любой сложности.
Даже без визивига есть ограничения — элемент нужно элементарно выбрать и сделать, чтобы он никуда не убегал (привет, слайдер! =)). Чтобы показать кнопку редактирования. Без этого можно обойтись, если дублировать где-то в слое админки все элементы в табличном виде, эдакая админка-в-панельке. Но это, опять же, уводит нас от контекста, плюс возникают проблемы с редактированием данных, попавших на страницу через разнообразные выборки-зеркала (последние новости, лучшие комментарии и т.д.).
То есть сделать условно-контекстную админку с табличными списками — можно, и наверное нужно, иногда работа с данными в таком виде гораздо удобнее. Но не как единственный-основной способ получения доступа к контенту.
P.S. Долго пытался вспомнить, где же я видел человека в шлеме. Вспомнил: вот здесь! Ах, милая я.рушка… Почти восемь лет, однако =)
P.P.S. Еще раз спасибо за комментарий по существу. Надеюсь, по размеру моего ответа остальные хабражители поймут, насколько сильно мы хотим поговорить о нашем интерфейсе, и тоже что-нибудь про него расскажут или спросят =)
Привет! :) Тоже увидел знакомую аватарку в комментариях, понял что серьезные люди делают проект :), захотелось обсудить интерфейс. Молодцы, что пытаетесь решить реально сложную системную задачу.
Нравится идея отделить компоновку, конструирование облика сайта от процесса наполнения-редактирования. Это сильно разные виды деятельности, разные этапы жизни сайта. Полагаю, что облик и отступы должен придумывать дизайнер, а пользователь выбирать шаблоны и вводить тексты. Здесь есть место заработать дизайнеру и, может быть, заработать программисту.
Нравится идея отделить компоновку, конструирование облика сайта от процесса наполнения-редактирования. Это сильно разные виды деятельности, разные этапы жизни сайта. Полагаю, что облик и отступы должен придумывать дизайнер, а пользователь выбирать шаблоны и вводить тексты. Здесь есть место заработать дизайнеру и, может быть, заработать программисту.
Нравится идея отделить компоновку, конструирование облика сайта от процесса наполнения-редактирования. Это сильно разные виды деятельности, разные этапы жизни сайта.
Безусловно. Настолько разные, что у нас долгое время было два режима: «Редактирование» для правки контента и «Дизайн» для добавления/настройки блоков. Мы их в итоге объединили, потому что собственно контент тоже может состоять из блоков (например, если нужно собрать лонг-рид из множества этажей, с каверами, врезками, галереями и т.д.). А режим «Дизайн» люди не видели и не понимали. Поэтому сейчас все контролы доступны в «Редактировании». Но мы планируем все-таки решить задачу их разделения, через систему прав — «крутой» пользователь может добавлять любые блоки куда угодно, а «редактор» — только на созданные им страницы в ограниченный набор областей, примерно так.
Полагаю, что облик и отступы должен придумывать дизайнер, а пользователь выбирать шаблоны и вводить тексты.
Мы тоже так считаем. Но на практике, когда даешь пользователю выбирать, дизайнеру и верстальщику приходится решать много очень тонких и интересных задачек, продумывая, как тот или иной шаблон будет вести себя в разных окружениях. Нам в этом очень помогает БЭМ-методология, но даже ее кунг-фу местами не хватает. Например, когда друг в друга оказываются вложены одноименные блоки (набор колонок, вставленный в другую колонку), или когда внешний вид элемента зависит от контекста, куда помещен блок (текст шрифта меню должен быть белым, если меню стоит в шапке, или черным, если меню попало куда-то еще). Пока такие задачки решаются не очень системно. Планирую грузануть ребят из Яндекса, когда наберется достаточно подобных головоломок =)
1. Программная архитектура обычному пользователю не интересна. Однако, как быть с программистами, обслуживающими сайт? Насколько система понятна обычному веб-программисту? Есть ли API, документация? Возможно ли создавать дополнительные модули?
2. Подход полного WYSiWYG безусловно удобен для пользователя. Беда в том, что в итоге получается едва ли не как в MS Word. Там тоже можно страницы создавать. Вот только по итоге там столько мусора в итоге оказывается. Проблему избыточности генерируемого WYSIWYG-кода решили? Пользователю, конечно, не нужна программная архитектура, но в большинстве случаев владелец сайта либо разбирается в базовых принципах веб-программирования, либо поручает это специально нанятому веб-мастеру.
3. Как обстоят дела с масштабируемостью данных? Допустим, есть пользователи. Каким образом, если это вообще возможно, добавлять дополнительные поля БЕЗ лишних тонн… программного кода? Тот же вопрос про дополнительные поля страниц и дополнительные модели.
Резюмируя сказанное прежде всего хочу отметить, что в большинстве случаев заказчик сайта доверяет дело программисту/веб-разработчику/вменяемому (или не очень) фрилансеру, не заботясь о стилях. Системы, ориентированные исключительно на пользователя, уже создавались. Ничего хорошего из этого не вышло. Взять хотя бы «джумлу», от одного упоминания о которой у меня начинается икота и нервное дёргание глазиком. Заказчик заказывает сайт разработчику, и его не заботит, что к чему. В качестве примера изучите MODX Evolution. Это как раз система, которая и для пользователя удобна и программисту доступна и удобна.
2. Подход полного WYSiWYG безусловно удобен для пользователя. Беда в том, что в итоге получается едва ли не как в MS Word. Там тоже можно страницы создавать. Вот только по итоге там столько мусора в итоге оказывается. Проблему избыточности генерируемого WYSIWYG-кода решили? Пользователю, конечно, не нужна программная архитектура, но в большинстве случаев владелец сайта либо разбирается в базовых принципах веб-программирования, либо поручает это специально нанятому веб-мастеру.
3. Как обстоят дела с масштабируемостью данных? Допустим, есть пользователи. Каким образом, если это вообще возможно, добавлять дополнительные поля БЕЗ лишних тонн… программного кода? Тот же вопрос про дополнительные поля страниц и дополнительные модели.
Резюмируя сказанное прежде всего хочу отметить, что в большинстве случаев заказчик сайта доверяет дело программисту/веб-разработчику/вменяемому (или не очень) фрилансеру, не заботясь о стилях. Системы, ориентированные исключительно на пользователя, уже создавались. Ничего хорошего из этого не вышло. Взять хотя бы «джумлу», от одного упоминания о которой у меня начинается икота и нервное дёргание глазиком. Заказчик заказывает сайт разработчику, и его не заботит, что к чему. В качестве примера изучите MODX Evolution. Это как раз система, которая и для пользователя удобна и программисту доступна и удобна.
Спасибо за интерес к нашей цмске. Постараюсь ответить по пунктам.
У нас пока нет достаточной статистики, чтобы утверждать, что система понятна обычному веб-программисту. Но есть все предпосылки надеяться, что так и будет. Жизнь покажет, следите за новостями =) Пока мы только хотели показать пользовательский интерфейс, посмотреть, как люди будут на него реагировать. Кстати, спасибо Хабру, данных для анализа набралось немало.
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 ковырял довольно плотно. И к нему у меня есть претензии, хотя озвучивать их прямо здесь, наверное, не стоит. Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной, хотя соблазн их размножить — был :)
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 ковырял довольно плотно. И к нему у меня есть претензии, хотя озвучивать их прямо здесь, наверное, не стоит. Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной, хотя соблазн их размножить — был :)
«Посмотрите внимательно на наш WYSIWYG»
Вижу, contenteditable. Если попробовать поработать с Вашим продуктом, скажем, в том же «ослике», оно будет работать? Вы уверены? А если пользователь захочет изменить дизайн, к кому он должен обращаться — к Вашей компании или к любому программисту? Насколько легко осваивается создание/кастомизация шаблонов для Вашей системы?
«добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);»
«Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов.»
— Дрынц! — сказала электропила.
— Ага! — сказали суровые сибирские мужики и пошли дальше валить лес топорами.
То есть для того, чтобы банально сделать анкетирование на сайте или простой каталог, нужно нагов… накодить ещё пару килограммов кода? Именно поэтому я и советовал ещё раз пристально изучить MODX (притом именно Evolution, к Revo у меня самого масса претензий). Добавляем в Evo TV-параметр к шаблону и дело в шляпе. Он отображается в форме ресурса, прекрасно создаётся/сохраняется в базе и, если вывести переменную в шаблон, отображается. В сущности и кодить почти не приходится. А создать простейший фильтр на TV-шках — дело минут десяти и пары десятков строк кода в простом сниппете.
«Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной»
Минуточку, а сама по себе концепция чанков у Вас реализована? Или написание шаблона под Вашу систему схоже с написанием шаблона под «неназываемую-от-которой-нервный-тик»? А сниппеты? Мне вот нужно вывести какую-то простейшую информацию с сайта друга, которую я дёргаю при помощи curl. Мне для этого нужно писать целый модуль?
Вижу, contenteditable. Если попробовать поработать с Вашим продуктом, скажем, в том же «ослике», оно будет работать? Вы уверены? А если пользователь захочет изменить дизайн, к кому он должен обращаться — к Вашей компании или к любому программисту? Насколько легко осваивается создание/кастомизация шаблонов для Вашей системы?
«добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);»
«Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов.»
— Дрынц! — сказала электропила.
— Ага! — сказали суровые сибирские мужики и пошли дальше валить лес топорами.
То есть для того, чтобы банально сделать анкетирование на сайте или простой каталог, нужно нагов… накодить ещё пару килограммов кода? Именно поэтому я и советовал ещё раз пристально изучить MODX (притом именно Evolution, к Revo у меня самого масса претензий). Добавляем в Evo TV-параметр к шаблону и дело в шляпе. Он отображается в форме ресурса, прекрасно создаётся/сохраняется в базе и, если вывести переменную в шаблон, отображается. В сущности и кодить почти не приходится. А создать простейший фильтр на TV-шках — дело минут десяти и пары десятков строк кода в простом сниппете.
«Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной»
Минуточку, а сама по себе концепция чанков у Вас реализована? Или написание шаблона под Вашу систему схоже с написанием шаблона под «неназываемую-от-которой-нервный-тик»? А сниппеты? Мне вот нужно вывести какую-то простейшую информацию с сайта друга, которую я дёргаю при помощи curl. Мне для этого нужно писать целый модуль?
Вижу, 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://...') пока можно, выражения не фильтруются). Суть та же.
Ещё совет. Раз так печётесь о визуальной стороне интерфейса, «приятности для глаза», то подумайте также о типографике, или как это называется. Например, во фразе «Семейная фотография с домашними животными» между «с» и «домашними» ставьте автоматом nbsp, чтобы строка вдруг не кончилась на союзе. Реализацию всяких правил можно подсмотреть у Лебедева в его Типографе.
Привет, спасибо, о типографике мы уже =) Вот пример с домашними: joxi.ru/a2XQZnWcq57aAg 3-4 строками я продублировал то же самое, но с подчерком вместо пробела, чтобы показать что пробел+предлог умещаются в строку. На видео это не понятно, потому что предлог переносится просто из-за нехватки места в строке.
Ну и кавычки-ёлочки, и mdash тоже. Одна (временная) проблема, пока не успели прикрутить к формам, работает только при иплейсном редактировании.
Использован типограф Дениса Селезнева github.com/typograf/typograf Для работы в realtime его пришлось пропатчить, сделав компиляцию регулярок одноразовой и изменив несколько правил, которые давали неожиданный результат на границе текста (типограф изначально рассчитан на ситуацию «текст уже написан, теперь мы его типографируем», а тут надо типографить прямо в процессе набора).
Как только найдется время осмыслить, как эти изменения могут повлиять на штатную работу, обязательно оформим pull request.
Ну и кавычки-ёлочки, и mdash тоже. Одна (временная) проблема, пока не успели прикрутить к формам, работает только при иплейсном редактировании.
Использован типограф Дениса Селезнева github.com/typograf/typograf Для работы в realtime его пришлось пропатчить, сделав компиляцию регулярок одноразовой и изменив несколько правил, которые давали неожиданный результат на границе текста (типограф изначально рассчитан на ситуацию «текст уже написан, теперь мы его типографируем», а тут надо типографить прямо в процессе набора).
Как только найдется время осмыслить, как эти изменения могут повлиять на штатную работу, обязательно оформим pull request.
«Он состоит из почти 10к строк кода»
Хм… Интересно, сколько весит Ваша система в итоге?
«Простой каталог и анкетирование приходится говнокодить независимо от платформы»
Кхм-кхм! Каталог в том же MODX делается без кодинга вообще. Создаём TV-параметры, цепляем их к шаблонам товаров, создаём товары — profit! И для того, чтобы показывалось, нужно просто воткнуть параметр (несколько символов) в нужное место шаблона. Я говорю не о шаблонах, о обработчиках, которые реализуют, скажем, логику каталога, добавления туда товаров, работы с товарами и т.п… Но коли уж Вы оговорились, что кодинг в Вашей системе нужен только для реализации специфичного поведения обработчика, то ОК, посмотрим на практике.
«А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД»
Именно поэтому я в своё время разработал парсер QuadBraces (поищите, есть на хабре), который работает с файловой системой, а не с БД. А нервный тик у меня вызывает система, в которой логика шаблонов бесструктурна и непрозрачна. Например, у меня будут общие для всех страниц хедер и футер. А контент будет отображаться в зависимости от шаблона. И не свитчами в одном файле, а именно чанками.
Это в «хомяках» достаточно одного шаблона. А, скажем, в интернет-магазинах уже нужно будет порядка десятка разных шаблонов.
«Если никуда не спешить, можно PHP-код разделить на модель+контроллер»
Ради того, чтобы дёрнуть с партнёрского сайта крохотную XML-ку и вывести информацию из неё в какое-то место сайта, плодить контроллеры и модели? Жуть какая!
Повторное использование кода, кстати, это очень актуальный вопрос. Допустим, у меня есть десять проектов на одной и той же CMS. Как у вас обстоят дела с повторным использованием кода ядра CMS, дабы не хранить его в 10 экземплярах на хостинге?
Хм… Интересно, сколько весит Ваша система в итоге?
«Простой каталог и анкетирование приходится говнокодить независимо от платформы»
Кхм-кхм! Каталог в том же MODX делается без кодинга вообще. Создаём TV-параметры, цепляем их к шаблонам товаров, создаём товары — profit! И для того, чтобы показывалось, нужно просто воткнуть параметр (несколько символов) в нужное место шаблона. Я говорю не о шаблонах, о обработчиках, которые реализуют, скажем, логику каталога, добавления туда товаров, работы с товарами и т.п… Но коли уж Вы оговорились, что кодинг в Вашей системе нужен только для реализации специфичного поведения обработчика, то ОК, посмотрим на практике.
«А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД»
Именно поэтому я в своё время разработал парсер QuadBraces (поищите, есть на хабре), который работает с файловой системой, а не с БД. А нервный тик у меня вызывает система, в которой логика шаблонов бесструктурна и непрозрачна. Например, у меня будут общие для всех страниц хедер и футер. А контент будет отображаться в зависимости от шаблона. И не свитчами в одном файле, а именно чанками.
{{pagehead}}
<!-- здесь будет произвольный код, зависящий от конкретного шаблона -->
{{pagefoot}}Это в «хомяках» достаточно одного шаблона. А, скажем, в интернет-магазинах уже нужно будет порядка десятка разных шаблонов.
«Если никуда не спешить, можно PHP-код разделить на модель+контроллер»
Ради того, чтобы дёрнуть с партнёрского сайта крохотную XML-ку и вывести информацию из неё в какое-то место сайта, плодить контроллеры и модели? Жуть какая!
Повторное использование кода, кстати, это очень актуальный вопрос. Допустим, у меня есть десять проектов на одной и той же CMS. Как у вас обстоят дела с повторным использованием кода ядра CMS, дабы не хранить его в 10 экземплярах на хостинге?
Хм… Интересно, сколько весит Ваша система в итоге?
Ну вот последняя собранная версия — 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 экономия будет не особо заметной.
Эх, не так я поставил вопрос. Сколько весит ядро системы? Вот так будет правильнее. Насчёт кейса тогда буду на связи, пишите в личку. Думаю, будет интересно.
> Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика.
Стоп, стоп! Вынесение не в шаблоны, а чанки, то есть кусочки HTML-кода. И зачем куча открывающих тегов. Чанк в нормальных шаблонизаторах вызывается односложной конструкцией. И здесь вопрос прежде всего в решении проблемы различия вёрстки от страницы к странице. Например, для технических и одиночных страниц (сингл-враппер) шаблон может быть таким (QuadBraces):
Шаблон же товара уже будет вот таким, например:
Притом, в чанке side может быть определена логика показа блоков не просто на той или иной странице, а на том или ином типе страницы (в моей CMS, кстати, которую я сейчас завершаю, это определяется, т.н. филдсетами).
То есть я о вёрстке, а не о выводе как таковых данных. Поехали дальше =)
> Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак
Это о предположительно паре десятков строк?! Вы шутите? Писать модель-контроллер ради функционала, который пишется на коленке и сломаться не может по определению, поскольку там просто нечему ломаться? Вы меня, конечно, простите, но я бессменно уже несколько лет ржу в голос над такими «серьёзными пацанами», которые ради пары действий плодят килобайты, а то и десятки килобайт говнокода; которые ради того, что можно сделать вообще статикой подключают массивные фреймворки. О дальнейшем развитии проекта хотите спросить? А вот как раз здесь нужно думать, где стоит утягивать пол-гитхаба под проект, а где достаточно наговнокодить пару десятков строк.
> Обычно под повторным использованием подразумевается немного
> другое — когда для реализации отличий в поведении не нужно копипастить
> код целиком и править нужное место, а достаточно передать необходимые
> параметры.
То, что Вы сейчас описали — это базовая парадигма функционального программирования. Пишем функцию и используем её, передавая каждый раз разные параметры. Повторное использование кода — это когда мы используем один и тот же код, подключая его из разных мест. Условно говоря, на хостинге лежит библиотека, а мы её подключаем в проекты из разных мест. Насчёт несущественности экономии места — расскажите это владельцам аккаунтов на шаред-хостингах, которые держат по десятку магазинов. Ога, для них ващщщщщще несущественно иметь 50 мегабайт вместо 5. Особенно когда на аккаунте не больше пары гигабайт вместе с базой и почтой. Так что такой подход как раз очень даже существеннен, если без сарказмы. Кстати, ещё немного похвалюсь будущим своим продуктом. У меня реализована концепция динамического репозитория, когда в проекте можно не только использовать код общего ядра, но и, скажем, переопределять базовые классы системы.
А наш с Вами диалог, однако ж, обретает всё большую конструктивность =)
> Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика.
Стоп, стоп! Вынесение не в шаблоны, а чанки, то есть кусочки HTML-кода. И зачем куча открывающих тегов. Чанк в нормальных шаблонизаторах вызывается односложной конструкцией. И здесь вопрос прежде всего в решении проблемы различия вёрстки от страницы к странице. Например, для технических и одиночных страниц (сингл-враппер) шаблон может быть таким (QuadBraces):
{{pagehead}}
[*content*]
{{pagefoot}}Шаблон же товара уже будет вот таким, например:
{{pagehead}}
<div class="ws">
<div class="side">{{side}}</div>
<div class="content">
<!-- здесь будет логика вывода товара -->
</div>
</div>
{{pagefoot}}Притом, в чанке side может быть определена логика показа блоков не просто на той или иной странице, а на том или ином типе страницы (в моей CMS, кстати, которую я сейчас завершаю, это определяется, т.н. филдсетами).
То есть я о вёрстке, а не о выводе как таковых данных. Поехали дальше =)
> Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак
Это о предположительно паре десятков строк?! Вы шутите? Писать модель-контроллер ради функционала, который пишется на коленке и сломаться не может по определению, поскольку там просто нечему ломаться? Вы меня, конечно, простите, но я бессменно уже несколько лет ржу в голос над такими «серьёзными пацанами», которые ради пары действий плодят килобайты, а то и десятки килобайт говнокода; которые ради того, что можно сделать вообще статикой подключают массивные фреймворки. О дальнейшем развитии проекта хотите спросить? А вот как раз здесь нужно думать, где стоит утягивать пол-гитхаба под проект, а где достаточно наговнокодить пару десятков строк.
> Обычно под повторным использованием подразумевается немного
> другое — когда для реализации отличий в поведении не нужно копипастить
> код целиком и править нужное место, а достаточно передать необходимые
> параметры.
То, что Вы сейчас описали — это базовая парадигма функционального программирования. Пишем функцию и используем её, передавая каждый раз разные параметры. Повторное использование кода — это когда мы используем один и тот же код, подключая его из разных мест. Условно говоря, на хостинге лежит библиотека, а мы её подключаем в проекты из разных мест. Насчёт несущественности экономии места — расскажите это владельцам аккаунтов на шаред-хостингах, которые держат по десятку магазинов. Ога, для них ващщщщщще несущественно иметь 50 мегабайт вместо 5. Особенно когда на аккаунте не больше пары гигабайт вместе с базой и почтой. Так что такой подход как раз очень даже существеннен, если без сарказмы. Кстати, ещё немного похвалюсь будущим своим продуктом. У меня реализована концепция динамического репозитория, когда в проекте можно не только использовать код общего ядра, но и, скажем, переопределять базовые классы системы.
А наш с Вами диалог, однако ж, обретает всё большую конструктивность =)
Эх, не так я поставил вопрос. Сколько весит ядро системы? Вот так будет правильнее.
Посчитал, 900кб в архиве, 3мб если распаковать. Ну и там еще есть что почистить.
Насчёт кейса тогда буду на связи, пишите в личку. Думаю, будет интересно.
Напишу непременно, ок ;)
Стоп, стоп! Вынесение не в шаблоны, а чанки, то есть кусочки HTML-кода.
Это у вас чанки — не шаблоны, а по сути вполне шаблоны, называются просто иначе.
И зачем куча открывающих тегов. Чанк в нормальных шаблонизаторах вызывается односложной конструкцией.
Куча открывающих тегов не при вызове, а в коде самого шаблона (ок, чанка :)). Если вызов выглядит так:
{{pagehead}}
...
{{pagefoot}}
То в коде pagehead будет что-то типа:
<html>
<head>...</head>
<body>
<div class="bg_wrapper">
<div class="size_wrapper">
<header>...</header>
<section class="content">
А в pagefoot соответственно так:
</section>
<footer>...</footer>
</div> <!-- eof size_wrapper -->
</div> <!-- eof bg_wrapper -->
</body>
</html>
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, соответственно, на шареде тоже заведется.
> Верстка-то одна, хидер-контент-сайдбар-футер.
Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее. Насчёт логики вопрос. Допустим есть такая композиция сайдбара (синтаксис QuadBraces):
В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
> подход с «активным типизированным шаблоном» проще и очевиднее,
> но офигительно проигрывает в гибкости
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
> Я таких очень давно не видел, но знаю, что они есть.
А у меня таких заказчиков большинство.
Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее. Насчёт логики вопрос. Допустим есть такая композиция сайдбара (синтаксис QuadBraces):
<div class="sidebar">
{{goodies-menu}}
[*resourceid:is=`[(home_page_id)]`:then=`{{ads-block-top}}`:else=`{{ads-block-page}}`*]
[*actionsids:notempty=`[!resources &ids=`[*actionsids*]` &template=`action-short`!]`*]
</div>В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
> подход с «активным типизированным шаблоном» проще и очевиднее,
> но офигительно проигрывает в гибкости
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
> Я таких очень давно не видел, но знаю, что они есть.
А у меня таких заказчиков большинство.
Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее.
Ну так чем она сложнее, тем актуальнее то, о чем я говорю. Если на сайте много разношерстных лейаутов, умножение их на «экраны» (т.е. наборы одновременно отображаемых блоков) может привести к анархии.
В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
В нашей CMS это будет выглядеть так:
<div class="sidebar" fx:area="sidebar"></div>
:) Это все, что тут требуется от шаблона. Дальше все делается мышкой, порядок такой:
- Идем на главную, жмем «добавить блок сюды» в сайдбаре. Выбираем нужный тип блока для рекламы на главной, в поле «Где показывать» — «Только эта страница».
- Идем на любую внутреннюю, опять жмем «добавить блок», выбираем блок, в поле «Где показывать» — «Только потомки страницы „Главная“» (т.е. все внутренние).
- Идем на страницу категории, все то же самое, «Где показывать» — «Потомки раздела „Магазин“, имеющие тип „Категория товаров“».
Итого: блоки стоят где надо, в нужном порядке, без правки шаблона. Пункты 1 и 2 можно объединить в один блок, зависит от реализации крутилки (надо ли настраивать место показа на уровне отдельного банера).
Я не очень понял, как добывать акции. Я сегодня слишком мало спал, чтобы прямо сейчас расшифровать этот
Как вариант, если считать, что акции лежат где-то отдельно (например, в разделе «Новости»):
- У «Акции» добавляем поле «Связанная категория каталога» (тип поля — «связь с другим объектом», в форме будет выглядеть как поисковая строка с ajax-подсказками).
- При добавлении блока на страницах категорий выбираем тип «Данные по фильтру» — «Услуги». Во вкладке «Условия» добавляем условие, в первой выпадушке выбираем поле «Связанная категория каталога», во второй — «Текущая страница».
Можно даже сделать, чтобы у акции было несколько категорий. Примерно так же, только кликов больше =) Трюк со значением «текущая страница» в условии не пройдет, если мы хотим показывать блок не только на самой странице категории, но и внутри нее (например, на странице товара). Но про такой кейс мы помним и, как только будет, на чем наглядно показать, мы его реализуем, добавив во вторую выпадушку варианты «ближайший предок, имеющий тип...» + выбор типа, и «предок N-го уровня (название)», собственно, находящий нужный элемент сверху вниз по хлебным крошкам. (Я начинаю понимать, почему начальство меня часто спрашивает, точно ли у нас не получится что-то типа друпала, снова эта картинка).
Кстати, а в ModX этот сценарий разруливается?
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
Ну так вы же не спорите =) я это и написал — такой подход проще, ибо очевиднее. Вопрос только в цене.
А у меня таких заказчиков большинство.
Значит вы мало сил уделяете воспитательной работе. Открою секрет, большинство клиентов (как минимум в Мск.) готовы не задумываясь отдать за хостинг сумму где-то между топовым VPS и дохленьким дедиком, лишь бы работало. Если есть знакомые из веб-студий — поспрашивайте, кто почем продает хостинг, очень удивитесь.
> Я не очень понял, как добывать акции.
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
А насчёт хостингов я скажу так. Воспитывать клиента (не считая моей строгости в вопросах постановки ТЗ) — не моя работа. Ну, по крайней мере впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет. Поэтому обычно всё ограничивается банальными шаредами вроде типовых предложений свеба, с которым, кстати, у меня почти есть партнёрка. Результат: клиент доволен итоговой стоимостью проекта, стоимостью и качеством хостинга, а я имею деньги и хороший ценный опыт. Поверьте, это куда ценнее, чем багаж из стека весьма тяжёлых технологий. Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса». Кстати, идея инфоблоков не оттуда ли взята? =)
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
А насчёт хостингов я скажу так. Воспитывать клиента (не считая моей строгости в вопросах постановки ТЗ) — не моя работа. Ну, по крайней мере впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет. Поэтому обычно всё ограничивается банальными шаредами вроде типовых предложений свеба, с которым, кстати, у меня почти есть партнёрка. Результат: клиент доволен итоговой стоимостью проекта, стоимостью и качеством хостинга, а я имею деньги и хороший ценный опыт. Поверьте, это куда ценнее, чем багаж из стека весьма тяжёлых технологий. Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса». Кстати, идея инфоблоков не оттуда ли взята? =)
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
Все равно не понимаю =)
1. [*actionsids*] — это свойство текущей страницы, правильно? Как оно заполняется, на уровне интерфейса? Что нужно, чтобы добавить акцию к категории? Найти нужный айдишник и вписать в текстовое поле после запятой?
2. Если категория — не текущая страница, а одна из родительских (например, мы смотрим страницу товара) — можно ли достать айдишники ее акций, если да, то как?
впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет
Если бы выделенный сервер действительно чудесным образом позволял писать вдвое меньше кода, не пользоваться этой возможностью было бы преступлением против заказчика.
Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса».
Не худшая судьба, если смотреть на метрики: 3-е место по рунету среди всех систем, включая бесплатные, и первое с запасом среди платных.
Кстати, идея инфоблоков не оттуда ли взята? =)
Напомните, пожалуйста, что такое «инфоблок» в их терминологии.
Для начала о задаче с акциями. Упрощу: [*actionsids*] заполняется вручную. Списываем нужные айдишники из дерева ресурсов через запятую. Если параметр не заполнен, не выводится ничего. Всё просто. Далее этот параметр передаётся сниппету, который получает нужные данные и выводит их по определённому шаблону.
Теперь о заказчиках. Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер. Заказчик не обязан приобретать выделенный сервер лишь из-за моей лени. Если ему требуется лендинг, я тупо заюзаю парсер QuadBraces, небольшой класс мейлера и, может быть, если понадобится, mysqli. Не кошерно? Ну, простите, зато работать будет даже на самом говённом шареде. Кстати, при наличии знаний работы на самом деле порой даже меньше, чем в случае с фреймворками.
Далее о рейтингах. В официальных рейтингах одно, на практике другое. Официальные рейтинги часто врут. Кроме того, увы, заказчик часто идёт на поводу у разработчика. Из-за чего в рунете можно частенько увидеть, скажем, лендинг на «Битриксе». Зачем? А всё очень просто — впарили.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных. Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
И, ещё раз касаясь темы инфоблоков, опять вернусь к своей CMS. У меня тоже можно делать модули. Однако, во-первых, формат дополнительных полей везде одинаков, унифицирован. В результате описания всех дополнительных полей для всех модулей хранятся в одной таблице. Далее значения. Все значения (nodetype отличен от нуля — не настройка) хранятся в типовых таблицах, каждая запись которых — три поля: ID поля, ID связанного ресурса (под ресурсом в данном случае может понимать, скажем, пользователь) и значение поля. Если модуль добавляет, скажем, SEO-настройки к ресурсам-страницам, значения будут храниться в уже имеющейся таблице значений полей ресурсов. Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц и соблюдается целостность данных (я использую InnoDB вместо MyISAM; могу себе позволить благодаря общему быстродействию движка). Кроме того, модель ресурса-страницы или ресурса-пользователя всегда получает все дополнительные поля, к которым у текущего пользователя есть доступ. Удалили модуль — удалилось всё связанное с ним. Удалили ресурс — удалилось всё связанное с ним. И глюков нет, и лишнего не хранится.
Теперь о заказчиках. Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер. Заказчик не обязан приобретать выделенный сервер лишь из-за моей лени. Если ему требуется лендинг, я тупо заюзаю парсер QuadBraces, небольшой класс мейлера и, может быть, если понадобится, mysqli. Не кошерно? Ну, простите, зато работать будет даже на самом говённом шареде. Кстати, при наличии знаний работы на самом деле порой даже меньше, чем в случае с фреймворками.
Далее о рейтингах. В официальных рейтингах одно, на практике другое. Официальные рейтинги часто врут. Кроме того, увы, заказчик часто идёт на поводу у разработчика. Из-за чего в рунете можно частенько увидеть, скажем, лендинг на «Битриксе». Зачем? А всё очень просто — впарили.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных. Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
И, ещё раз касаясь темы инфоблоков, опять вернусь к своей CMS. У меня тоже можно делать модули. Однако, во-первых, формат дополнительных полей везде одинаков, унифицирован. В результате описания всех дополнительных полей для всех модулей хранятся в одной таблице. Далее значения. Все значения (nodetype отличен от нуля — не настройка) хранятся в типовых таблицах, каждая запись которых — три поля: ID поля, ID связанного ресурса (под ресурсом в данном случае может понимать, скажем, пользователь) и значение поля. Если модуль добавляет, скажем, SEO-настройки к ресурсам-страницам, значения будут храниться в уже имеющейся таблице значений полей ресурсов. Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц и соблюдается целостность данных (я использую InnoDB вместо MyISAM; могу себе позволить благодаря общему быстродействию движка). Кроме того, модель ресурса-страницы или ресурса-пользователя всегда получает все дополнительные поля, к которым у текущего пользователя есть доступ. Удалили модуль — удалилось всё связанное с ним. Удалили ресурс — удалилось всё связанное с ним. И глюков нет, и лишнего не хранится.
Для начала о задаче с акциями. Упрощу: [*actionsids*] заполняется вручную. Списываем нужные айдишники из дерева ресурсов через запятую. Если параметр не заполнен, не выводится ничего. Всё просто.
А если все-таки не упрощать? Или это вполне «продуктовый» вариант? Вы даете заказчикам вносить ID через запятую руками, правда? o_0
Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер.
На шареде заказчик попадает в зависимость от соседей. Это может очень неожиданно проявиться, как бы вы там ни писали свой код.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных.
Ну, плюс-минус так. И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
Раньше как раз была пара таблиц (четыре, если точнее). Называется EAV. И работало оно так себе. Не понимаете почему? Ок, ну напишите на бумажке какой-нибудь запрос с фильтром + сортировкой + группировкой на такую схему. Лет пять назад они ввели обычные «горизонтальные» таблицы как альтернативный способ хранения. Сейчас не знаю, но судя по вашим словам, его сделали основным.
Как устройство таблиц влияет на количество однотипного кода — вообще не понимаю. Если только не писать все запросы руками, но вроде бы за такое сейчас бьют по рукам.
Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц
Дайте угадаю. Вы большую часть своих клиентов посадили на какой-то супер-дешевый шаред, у которого есть ограничение на кол-во таблиц! А, или лучше: вы их засунули в один аккаунт, которому доступна одна БД, и разруливаете на префиксах! Тогда понятно, почему мысль о новых таблицах вас так пугает.
Серьезно, почитайте про entity-attribute-value: это подход для довольно специфических задач, и среди его преимуществ уж точно нет скорости.
> Вы даете заказчикам вносить ID через запятую руками, правда?
Если на MODX, то да. На моей системе существует специальный элемент ввода для выбора ресурсов.
> И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Терминологией. Пока не гляну код, точнее сказать не смогу
> Ок, ну напишите на бумажке какой-нибудь запрос
> с фильтром + сортировкой + группировкой на такую схему.
Без проблем написал =) Опять-таки же, если следовать концепции MVC, то сами по себе запросы генерируются моделями. А в модели хранится вся информация. Например, какие поля являются системными, какие дополнительными. Если реализовывать как-таковой запрос на получение данных с JOIN-ами, всё предельно просто. Получится что-то вроде этого:
Единственным ограничением такого подхода является необходимость следить за тем, чтобы алиасы дополнительных полей не совпадали с алиасами системных полей. И такой запрос сам по себе генерируется как раз моделью и уже только потом используется DBAPI движка.
> Дайте угадаю…
Не угадали. Вся фишка в том, что на одном аккаунте может быть десяток проектов в доступных для использования 4 базах. Тот же MODX для работы создаёт 39 таблиц. У меня же базовых таблиц, ЕМНИП, 16 штук. Как-то проще разобраться с базой, если в ней меньше таблиц, не находите?
Ну а теперь продолжим беседу о хостингах. Кстати, нет нужды ставить ссылку на комментарий. Всё равно в данном топике только мы с Вами ведём обсуждение. Так вот, собственно. На шареде ресурсы распределяются между пользователями сервера. Это бесспорно. И в общем-то Вы верно заметили, что можно попасть в зависимость от других пользователей. Однако, во-первых, редко сервер бывает забит полностью. Нормальный хостинг обычно оставляет некоторый запас по производительности. Во-вторых, давайте просто подумаем какие проекты нуждаются номинально в большом количестве ресурсов. Уж точно не сайты-визитки, «хомяки», лендинги и даже небольшие интернет-магазины. Шаред-хостинг предназначен для размещения сравнительно небольших проектов. И я веду речь о том, что не имеет смысла делать этот самый небольшой проект так, чтобы он требовал под себя отдельный сервер. Я б убил фрилансера без суда и следствия (фигурально выражаясь), если бы он мне сделал интернет-магазин на десяток товаров на том же Yii или Symphony. Использование фреймворков и тяжеловесных решений на мой взгляд оправдано только тогда, когда проект весьма крупен. А данном топике речь идёт о CMS под небольшие, насколько я понимаю, проекты (извините, уже сейчас я делаю выводы, что не стал бы использовать Вашу CMS под сложный проект). Иными словами всё должно быть соразмерно. Если CMS, то она не должна требовать под себя отдельный сервер. А делать, скажем, соцсеть на CMS — глупо.
Если на MODX, то да. На моей системе существует специальный элемент ввода для выбора ресурсов.
> И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Терминологией. Пока не гляну код, точнее сказать не смогу
> Ок, ну напишите на бумажке какой-нибудь запрос
> с фильтром + сортировкой + группировкой на такую схему.
Без проблем написал =) Опять-таки же, если следовать концепции MVC, то сами по себе запросы генерируются моделями. А в модели хранится вся информация. Например, какие поля являются системными, какие дополнительными. Если реализовывать как-таковой запрос на получение данных с JOIN-ами, всё предельно просто. Получится что-то вроде этого:
select
tmain.*,
t_myfield1.`value` as `myfield1`,
t_myfield2.`value` as `myfield2`
from `[+prefix+]resources` as tmain
left join `[+prefix+]resources_values` as t_myfield1 on ((t_myfield1.`field` = 1) and (t_myfield1.`resource` = tmain.`id`))
left join `[+prefix+]resources_values` as t_myfield2 on ((t_myfield2.`field` = 2) and (t_myfield2.`resource` = tmain.`id`))
Единственным ограничением такого подхода является необходимость следить за тем, чтобы алиасы дополнительных полей не совпадали с алиасами системных полей. И такой запрос сам по себе генерируется как раз моделью и уже только потом используется DBAPI движка.
> Дайте угадаю…
Не угадали. Вся фишка в том, что на одном аккаунте может быть десяток проектов в доступных для использования 4 базах. Тот же MODX для работы создаёт 39 таблиц. У меня же базовых таблиц, ЕМНИП, 16 штук. Как-то проще разобраться с базой, если в ней меньше таблиц, не находите?
Ну а теперь продолжим беседу о хостингах. Кстати, нет нужды ставить ссылку на комментарий. Всё равно в данном топике только мы с Вами ведём обсуждение. Так вот, собственно. На шареде ресурсы распределяются между пользователями сервера. Это бесспорно. И в общем-то Вы верно заметили, что можно попасть в зависимость от других пользователей. Однако, во-первых, редко сервер бывает забит полностью. Нормальный хостинг обычно оставляет некоторый запас по производительности. Во-вторых, давайте просто подумаем какие проекты нуждаются номинально в большом количестве ресурсов. Уж точно не сайты-визитки, «хомяки», лендинги и даже небольшие интернет-магазины. Шаред-хостинг предназначен для размещения сравнительно небольших проектов. И я веду речь о том, что не имеет смысла делать этот самый небольшой проект так, чтобы он требовал под себя отдельный сервер. Я б убил фрилансера без суда и следствия (фигурально выражаясь), если бы он мне сделал интернет-магазин на десяток товаров на том же Yii или Symphony. Использование фреймворков и тяжеловесных решений на мой взгляд оправдано только тогда, когда проект весьма крупен. А данном топике речь идёт о CMS под небольшие, насколько я понимаю, проекты (извините, уже сейчас я делаю выводы, что не стал бы использовать Вашу CMS под сложный проект). Иными словами всё должно быть соразмерно. Если CMS, то она не должна требовать под себя отдельный сервер. А делать, скажем, соцсеть на CMS — глупо.
Sign up to leave a comment.
4 правила интерфейсов управления контентом, которые никто не соблюдает