Поделюсь опытом. Опишу одну из своих методологий. Права на ресурсы определяются полубайтом «crud» (последовательность со старшего бита delete-read-update-create). Права на группу либо персональные права определяются упакованной записью-байтом, младший полубайт которой содержит переопределяющие права, старший — маску. Если в маске бит установлен в единицу, исходный бит переопределяется, иначе наследуется.
В самом ресурсе указывается доступ по умолчанию для семи основных (системных) групп (поле типа int), могущее иметь значение типа null, а также поле маски для дочерних ресурсов (ещё одно поле типа int). В случае с null дочерний ресурс наследует права родительского, и в этом случае применяется маска к доступам родительского ресурса. В ином случае применяется указанный в самом дочернем ресурсе доступ. Доступ к корневым ресурсам по умолчанию определяется настройкой системы.
Таблица групп представлена идентификатором группы, идентификатором ресурса, и байтом доступа с маской. Также есть таблица персональных прав пользователей. В ней вместо идентификатора группы находятся поле идентификатора пользователя. При определении прав пользователя сначала применяются права текущей системной группы пользователя исходя из прав, прописанных в самих ресурсах, затем по порядку (определённому в таблице самих групп) права групп, если пользователь принадлежит к какой-либо группе, затем, если существует запись в таблице индивидуальных прав (тот же принцип), применяются права конкретного пользователя.
Довольно сложно, но зато помогает чрезвычайно гибко определить права доступа к ресурсам.
Всё равно в стрелялки особо не поиграешь. Человеку в шутерах бегать много надобно. А пространство комнаты обычно существенно меньше пространства в игре. Так что надо либо изобретать полностью нейронный интерфейс, который будет погружать человека практически в состояние близкое к быстрому сну, где ощущения вполне себе реальны наряду с возможностями движения в игре без движения в реальном мире. Либо в довесок к подобным костюмам создавать системы-платформы. Правда, во втором случае весь обвес будет довольно-таки стационарным.
Не, ну шаблонизацией, конечно, грех не воспользоваться. Всё таки при изменениях в хедере сайта или в футере придётся лопатить все 8 страниц. Тут CSS уже не поможет. Но тут поможет любой автономный шаблонизатор. Хотя бы тот же QuadBraces (50 килобайт кода в одном файле). И в целом вопрос поставлен хороший. Всегда удивляло, когда лендинги те же делают на CMS-ках. Особенно на «битриксе». Это вообще сказка. Обычно отговариваются, дескать, развитие и всё такое. Какое нафиг развитие? Вы сначала трезво оцените, проживёт ли ваш проект вообще больше года-двух. Это раз. А во-вторых, развитие часто подразумевает основательную переделку. Тут хоть на какой CMS делай, один хрен придётся основательно потрудиться. Главное в разработке — проработка архитектуры. Если архитектура проработана грамотно, то и переделка пройдёт без проблем. Сразу продумывать где на что опираться.
Я б на месте авторов подал бы иск к РКН. Честно. Ребята вроде «Немного Нервно» раскручиваются в весьма немалой степени именно благодаря РТ. Коллективный иск немного охладил бы пыл РКН, я считаю.
Я удивляюсь правообладятлам. Сейчас век компьютеров. Если произведение можно увидеть или услышать, значит его можно скачать. Это банальная логика. Хоть какими средствами защиты пользуйся, один хрен взломают/скачают/сграбят. На что рассчитывают эти индивидуумы? Найдутся другие способы получать контент в обход авторских прав. А ведь положительный пример прямо под носом — Алексей Кортнев. Зайдите на сайт группы «Несчастный Случай» и скачайте любую композицию из их репертуара прямо с офсайта совершенно бесплатно. Основную массу денег коллектив получает с концертов, рекламы и т.п. Вот вам новая модель монетизации современного искусства — краудфандинг. Даже БГ свой новый альбом, ЕМНИП, писал на средства от краудфандинговой кампании. Он понял. Поймут ли мигалковы — вопрос хороший.
На случай вопросов вида «а-ты-что-писал». Я сам — музыкант, композитор, публикующий свои произведения в открытом виде.
Ну, блин, наконец-то! А то вечно приходилось придумывать костыли под интеграцию этой кнопки на сайты. Где шрифт убрать, где цвет подстроить. Теперь хоть проще стало.
> Вы даете заказчикам вносить ID через запятую руками, правда?
Если на 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 — глупо.
Для начала о задаче с акциями. Упрощу: [*actionsids*] заполняется вручную. Списываем нужные айдишники из дерева ресурсов через запятую. Если параметр не заполнен, не выводится ничего. Всё просто. Далее этот параметр передаётся сниппету, который получает нужные данные и выводит их по определённому шаблону.
Теперь о заказчиках. Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер. Заказчик не обязан приобретать выделенный сервер лишь из-за моей лени. Если ему требуется лендинг, я тупо заюзаю парсер QuadBraces, небольшой класс мейлера и, может быть, если понадобится, mysqli. Не кошерно? Ну, простите, зато работать будет даже на самом говённом шареде. Кстати, при наличии знаний работы на самом деле порой даже меньше, чем в случае с фреймворками.
Далее о рейтингах. В официальных рейтингах одно, на практике другое. Официальные рейтинги часто врут. Кроме того, увы, заказчик часто идёт на поводу у разработчика. Из-за чего в рунете можно частенько увидеть, скажем, лендинг на «Битриксе». Зачем? А всё очень просто — впарили.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных. Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
И, ещё раз касаясь темы инфоблоков, опять вернусь к своей CMS. У меня тоже можно делать модули. Однако, во-первых, формат дополнительных полей везде одинаков, унифицирован. В результате описания всех дополнительных полей для всех модулей хранятся в одной таблице. Далее значения. Все значения (nodetype отличен от нуля — не настройка) хранятся в типовых таблицах, каждая запись которых — три поля: ID поля, ID связанного ресурса (под ресурсом в данном случае может понимать, скажем, пользователь) и значение поля. Если модуль добавляет, скажем, SEO-настройки к ресурсам-страницам, значения будут храниться в уже имеющейся таблице значений полей ресурсов. Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц и соблюдается целостность данных (я использую InnoDB вместо MyISAM; могу себе позволить благодаря общему быстродействию движка). Кроме того, модель ресурса-страницы или ресурса-пользователя всегда получает все дополнительные поля, к которым у текущего пользователя есть доступ. Удалили модуль — удалилось всё связанное с ним. Удалили ресурс — удалилось всё связанное с ним. И глюков нет, и лишнего не хранится.
> Я не очень понял, как добывать акции.
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
А насчёт хостингов я скажу так. Воспитывать клиента (не считая моей строгости в вопросах постановки ТЗ) — не моя работа. Ну, по крайней мере впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет. Поэтому обычно всё ограничивается банальными шаредами вроде типовых предложений свеба, с которым, кстати, у меня почти есть партнёрка. Результат: клиент доволен итоговой стоимостью проекта, стоимостью и качеством хостинга, а я имею деньги и хороший ценный опыт. Поверьте, это куда ценнее, чем багаж из стека весьма тяжёлых технологий. Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса». Кстати, идея инфоблоков не оттуда ли взята? =)
> Верстка-то одна, хидер-контент-сайдбар-футер.
Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее. Насчёт логики вопрос. Допустим есть такая композиция сайдбара (синтаксис QuadBraces):
В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
> подход с «активным типизированным шаблоном» проще и очевиднее,
> но офигительно проигрывает в гибкости
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
> Я таких очень давно не видел, но знаю, что они есть.
А у меня таких заказчиков большинство.
Блин, вот на backdrop-filter я уже давно фапаю. Крутейшая штука, позволяющая в итоге создавать окошки в приложениях в стиле «семёрки». Точнее не сами окошки и заголовки оных с полупрозрачностью и размытием.
Эх, не так я поставил вопрос. Сколько весит ядро системы? Вот так будет правильнее. Насчёт кейса тогда буду на связи, пишите в личку. Думаю, будет интересно.
> Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика.
Стоп, стоп! Вынесение не в шаблоны, а чанки, то есть кусочки HTML-кода. И зачем куча открывающих тегов. Чанк в нормальных шаблонизаторах вызывается односложной конструкцией. И здесь вопрос прежде всего в решении проблемы различия вёрстки от страницы к странице. Например, для технических и одиночных страниц (сингл-враппер) шаблон может быть таким (QuadBraces):
{{pagehead}}
[*content*]
{{pagefoot}}
Шаблон же товара уже будет вот таким, например:
{{pagehead}}
<div class="ws">
<div class="side">{{side}}</div>
<div class="content">
<!-- здесь будет логика вывода товара -->
</div>
</div>
{{pagefoot}}
Притом, в чанке side может быть определена логика показа блоков не просто на той или иной странице, а на том или ином типе страницы (в моей CMS, кстати, которую я сейчас завершаю, это определяется, т.н. филдсетами).
То есть я о вёрстке, а не о выводе как таковых данных. Поехали дальше =)
> Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак
Это о предположительно паре десятков строк?! Вы шутите? Писать модель-контроллер ради функционала, который пишется на коленке и сломаться не может по определению, поскольку там просто нечему ломаться? Вы меня, конечно, простите, но я бессменно уже несколько лет ржу в голос над такими «серьёзными пацанами», которые ради пары действий плодят килобайты, а то и десятки килобайт говнокода; которые ради того, что можно сделать вообще статикой подключают массивные фреймворки. О дальнейшем развитии проекта хотите спросить? А вот как раз здесь нужно думать, где стоит утягивать пол-гитхаба под проект, а где достаточно наговнокодить пару десятков строк.
> Обычно под повторным использованием подразумевается немного
> другое — когда для реализации отличий в поведении не нужно копипастить
> код целиком и править нужное место, а достаточно передать необходимые
> параметры.
То, что Вы сейчас описали — это базовая парадигма функционального программирования. Пишем функцию и используем её, передавая каждый раз разные параметры. Повторное использование кода — это когда мы используем один и тот же код, подключая его из разных мест. Условно говоря, на хостинге лежит библиотека, а мы её подключаем в проекты из разных мест. Насчёт несущественности экономии места — расскажите это владельцам аккаунтов на шаред-хостингах, которые держат по десятку магазинов. Ога, для них ващщщщщще несущественно иметь 50 мегабайт вместо 5. Особенно когда на аккаунте не больше пары гигабайт вместе с базой и почтой. Так что такой подход как раз очень даже существеннен, если без сарказмы. Кстати, ещё немного похвалюсь будущим своим продуктом. У меня реализована концепция динамического репозитория, когда в проекте можно не только использовать код общего ядра, но и, скажем, переопределять базовые классы системы.
А наш с Вами диалог, однако ж, обретает всё большую конструктивность =)
Хм… Интересно, сколько весит Ваша система в итоге?
«Простой каталог и анкетирование приходится говнокодить независимо от платформы»
Кхм-кхм! Каталог в том же MODX делается без кодинга вообще. Создаём TV-параметры, цепляем их к шаблонам товаров, создаём товары — profit! И для того, чтобы показывалось, нужно просто воткнуть параметр (несколько символов) в нужное место шаблона. Я говорю не о шаблонах, о обработчиках, которые реализуют, скажем, логику каталога, добавления туда товаров, работы с товарами и т.п… Но коли уж Вы оговорились, что кодинг в Вашей системе нужен только для реализации специфичного поведения обработчика, то ОК, посмотрим на практике.
«А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД»
Именно поэтому я в своё время разработал парсер QuadBraces (поищите, есть на хабре), который работает с файловой системой, а не с БД. А нервный тик у меня вызывает система, в которой логика шаблонов бесструктурна и непрозрачна. Например, у меня будут общие для всех страниц хедер и футер. А контент будет отображаться в зависимости от шаблона. И не свитчами в одном файле, а именно чанками.
{{pagehead}}
<!-- здесь будет произвольный код, зависящий от конкретного шаблона -->
{{pagefoot}}
Это в «хомяках» достаточно одного шаблона. А, скажем, в интернет-магазинах уже нужно будет порядка десятка разных шаблонов.
«Если никуда не спешить, можно PHP-код разделить на модель+контроллер»
Ради того, чтобы дёрнуть с партнёрского сайта крохотную XML-ку и вывести информацию из неё в какое-то место сайта, плодить контроллеры и модели? Жуть какая!
Повторное использование кода, кстати, это очень актуальный вопрос. Допустим, у меня есть десять проектов на одной и той же CMS. Как у вас обстоят дела с повторным использованием кода ядра CMS, дабы не хранить его в 10 экземплярах на хостинге?
«Посмотрите внимательно на наш WYSIWYG»
Вижу, contenteditable. Если попробовать поработать с Вашим продуктом, скажем, в том же «ослике», оно будет работать? Вы уверены? А если пользователь захочет изменить дизайн, к кому он должен обращаться — к Вашей компании или к любому программисту? Насколько легко осваивается создание/кастомизация шаблонов для Вашей системы?
«добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);»
«Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов.»
— Дрынц! — сказала электропила.
— Ага! — сказали суровые сибирские мужики и пошли дальше валить лес топорами.
То есть для того, чтобы банально сделать анкетирование на сайте или простой каталог, нужно нагов… накодить ещё пару килограммов кода? Именно поэтому я и советовал ещё раз пристально изучить MODX (притом именно Evolution, к Revo у меня самого масса претензий). Добавляем в Evo TV-параметр к шаблону и дело в шляпе. Он отображается в форме ресурса, прекрасно создаётся/сохраняется в базе и, если вывести переменную в шаблон, отображается. В сущности и кодить почти не приходится. А создать простейший фильтр на TV-шках — дело минут десяти и пары десятков строк кода в простом сниппете.
«Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной»
Минуточку, а сама по себе концепция чанков у Вас реализована? Или написание шаблона под Вашу систему схоже с написанием шаблона под «неназываемую-от-которой-нервный-тик»? А сниппеты? Мне вот нужно вывести какую-то простейшую информацию с сайта друга, которую я дёргаю при помощи curl. Мне для этого нужно писать целый модуль?
1. Программная архитектура обычному пользователю не интересна. Однако, как быть с программистами, обслуживающими сайт? Насколько система понятна обычному веб-программисту? Есть ли API, документация? Возможно ли создавать дополнительные модули?
2. Подход полного WYSiWYG безусловно удобен для пользователя. Беда в том, что в итоге получается едва ли не как в MS Word. Там тоже можно страницы создавать. Вот только по итоге там столько мусора в итоге оказывается. Проблему избыточности генерируемого WYSIWYG-кода решили? Пользователю, конечно, не нужна программная архитектура, но в большинстве случаев владелец сайта либо разбирается в базовых принципах веб-программирования, либо поручает это специально нанятому веб-мастеру.
3. Как обстоят дела с масштабируемостью данных? Допустим, есть пользователи. Каким образом, если это вообще возможно, добавлять дополнительные поля БЕЗ лишних тонн… программного кода? Тот же вопрос про дополнительные поля страниц и дополнительные модели.
Резюмируя сказанное прежде всего хочу отметить, что в большинстве случаев заказчик сайта доверяет дело программисту/веб-разработчику/вменяемому (или не очень) фрилансеру, не заботясь о стилях. Системы, ориентированные исключительно на пользователя, уже создавались. Ничего хорошего из этого не вышло. Взять хотя бы «джумлу», от одного упоминания о которой у меня начинается икота и нервное дёргание глазиком. Заказчик заказывает сайт разработчику, и его не заботит, что к чему. В качестве примера изучите MODX Evolution. Это как раз система, которая и для пользователя удобна и программисту доступна и удобна.
Х.З… Как говорили выше, реклама рекламе рознь. Есть сайты с интеллигентной рекламой, например, Хабр. Реклама тут есть, её немало, но она хоть глаза не режет. А самое главное, здешняя реклама вписывается в дизайн сайта. Рекламу на видеохостингах в принципе можно понять. Главное, чтобы не перебарщивать. Смотреть 5 минут рекламы ради просмотра 30 секунд «прикольной видюшки» лично я не стану. Так что секунд 10-15 на ролик и исключительно в самом начале. А то я уже несколько раз сталкивался с рекламой через каждые минут 10 видео. Плюс многочисленные гифки, которые грузят страницу по самое «не-хочу». К слову сказать использование блокировщиков зачастую обуславливается желанием просто нормально сёрфить вместо минут ожидания, пока страница прогрузится вместе с тоннами рекламы.
Общий тезис: реклама должна быть ненавязчивой и гармонично вписываться в проект. Тогда и блокировщики начнут отмирать.
Следите за коммитами на гите. Я добавил функционал, позволяющий проходиться циклом по элементам массива data парсера, являющимися массивами. То есть теперь для вывода портфолио можно добавить в массив data парсера элемент с ключом, скажем, items и вывести портфолио вот так
{!items &chunk=`item`!}
Если каждый элемент массива, являясь в свою очередь массивом будет содержать, скажем, элементы с ключами id, title, desc, то итератор (в промежуточной стадии) выведет следующее:
В самом ресурсе указывается доступ по умолчанию для семи основных (системных) групп (поле типа int), могущее иметь значение типа null, а также поле маски для дочерних ресурсов (ещё одно поле типа int). В случае с null дочерний ресурс наследует права родительского, и в этом случае применяется маска к доступам родительского ресурса. В ином случае применяется указанный в самом дочернем ресурсе доступ. Доступ к корневым ресурсам по умолчанию определяется настройкой системы.
Таблица групп представлена идентификатором группы, идентификатором ресурса, и байтом доступа с маской. Также есть таблица персональных прав пользователей. В ней вместо идентификатора группы находятся поле идентификатора пользователя. При определении прав пользователя сначала применяются права текущей системной группы пользователя исходя из прав, прописанных в самих ресурсах, затем по порядку (определённому в таблице самих групп) права групп, если пользователь принадлежит к какой-либо группе, затем, если существует запись в таблице индивидуальных прав (тот же принцип), применяются права конкретного пользователя.
Довольно сложно, но зато помогает чрезвычайно гибко определить права доступа к ресурсам.
На случай вопросов вида «а-ты-что-писал». Я сам — музыкант, композитор, публикующий свои произведения в открытом виде.
Если на MODX, то да. На моей системе существует специальный элемент ввода для выбора ресурсов.
> И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Терминологией. Пока не гляну код, точнее сказать не смогу
> Ок, ну напишите на бумажке какой-нибудь запрос
> с фильтром + сортировкой + группировкой на такую схему.
Без проблем написал =) Опять-таки же, если следовать концепции MVC, то сами по себе запросы генерируются моделями. А в модели хранится вся информация. Например, какие поля являются системными, какие дополнительными. Если реализовывать как-таковой запрос на получение данных с JOIN-ами, всё предельно просто. Получится что-то вроде этого:
Единственным ограничением такого подхода является необходимость следить за тем, чтобы алиасы дополнительных полей не совпадали с алиасами системных полей. И такой запрос сам по себе генерируется как раз моделью и уже только потом используется DBAPI движка.
> Дайте угадаю…
Не угадали. Вся фишка в том, что на одном аккаунте может быть десяток проектов в доступных для использования 4 базах. Тот же MODX для работы создаёт 39 таблиц. У меня же базовых таблиц, ЕМНИП, 16 штук. Как-то проще разобраться с базой, если в ней меньше таблиц, не находите?
Ну а теперь продолжим беседу о хостингах. Кстати, нет нужды ставить ссылку на комментарий. Всё равно в данном топике только мы с Вами ведём обсуждение. Так вот, собственно. На шареде ресурсы распределяются между пользователями сервера. Это бесспорно. И в общем-то Вы верно заметили, что можно попасть в зависимость от других пользователей. Однако, во-первых, редко сервер бывает забит полностью. Нормальный хостинг обычно оставляет некоторый запас по производительности. Во-вторых, давайте просто подумаем какие проекты нуждаются номинально в большом количестве ресурсов. Уж точно не сайты-визитки, «хомяки», лендинги и даже небольшие интернет-магазины. Шаред-хостинг предназначен для размещения сравнительно небольших проектов. И я веду речь о том, что не имеет смысла делать этот самый небольшой проект так, чтобы он требовал под себя отдельный сервер. Я б убил фрилансера без суда и следствия (фигурально выражаясь), если бы он мне сделал интернет-магазин на десяток товаров на том же Yii или Symphony. Использование фреймворков и тяжеловесных решений на мой взгляд оправдано только тогда, когда проект весьма крупен. А данном топике речь идёт о CMS под небольшие, насколько я понимаю, проекты (извините, уже сейчас я делаю выводы, что не стал бы использовать Вашу CMS под сложный проект). Иными словами всё должно быть соразмерно. Если CMS, то она не должна требовать под себя отдельный сервер. А делать, скажем, соцсеть на CMS — глупо.
Теперь о заказчиках. Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер. Заказчик не обязан приобретать выделенный сервер лишь из-за моей лени. Если ему требуется лендинг, я тупо заюзаю парсер QuadBraces, небольшой класс мейлера и, может быть, если понадобится, mysqli. Не кошерно? Ну, простите, зато работать будет даже на самом говённом шареде. Кстати, при наличии знаний работы на самом деле порой даже меньше, чем в случае с фреймворками.
Далее о рейтингах. В официальных рейтингах одно, на практике другое. Официальные рейтинги часто врут. Кроме того, увы, заказчик часто идёт на поводу у разработчика. Из-за чего в рунете можно частенько увидеть, скажем, лендинг на «Битриксе». Зачем? А всё очень просто — впарили.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных. Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
И, ещё раз касаясь темы инфоблоков, опять вернусь к своей CMS. У меня тоже можно делать модули. Однако, во-первых, формат дополнительных полей везде одинаков, унифицирован. В результате описания всех дополнительных полей для всех модулей хранятся в одной таблице. Далее значения. Все значения (nodetype отличен от нуля — не настройка) хранятся в типовых таблицах, каждая запись которых — три поля: ID поля, ID связанного ресурса (под ресурсом в данном случае может понимать, скажем, пользователь) и значение поля. Если модуль добавляет, скажем, SEO-настройки к ресурсам-страницам, значения будут храниться в уже имеющейся таблице значений полей ресурсов. Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц и соблюдается целостность данных (я использую InnoDB вместо MyISAM; могу себе позволить благодаря общему быстродействию движка). Кроме того, модель ресурса-страницы или ресурса-пользователя всегда получает все дополнительные поля, к которым у текущего пользователя есть доступ. Удалили модуль — удалилось всё связанное с ним. Удалили ресурс — удалилось всё связанное с ним. И глюков нет, и лишнего не хранится.
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
А насчёт хостингов я скажу так. Воспитывать клиента (не считая моей строгости в вопросах постановки ТЗ) — не моя работа. Ну, по крайней мере впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет. Поэтому обычно всё ограничивается банальными шаредами вроде типовых предложений свеба, с которым, кстати, у меня почти есть партнёрка. Результат: клиент доволен итоговой стоимостью проекта, стоимостью и качеством хостинга, а я имею деньги и хороший ценный опыт. Поверьте, это куда ценнее, чем багаж из стека весьма тяжёлых технологий. Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса». Кстати, идея инфоблоков не оттуда ли взята? =)
Утрируете, любезный, сильно утрируете! Хорошая вёрстка бывает куда сложнее. Насчёт логики вопрос. Допустим есть такая композиция сайдбара (синтаксис QuadBraces):
В данном случае на главной показывается один блок с рекламой, на остальных страницах — другой. Плюс на страницах категорий товаров отображается блок с акциями для соответствующей категории товаров (если параметр actionsids не пуст). Сниппет resources — типовой сниппет, выводящий ресурсы с выбранными айдишниками по заданному шаблону. Возможна ли реализация чего-то подобного в Вашей CMS?
> подход с «активным типизированным шаблоном» проще и очевиднее,
> но офигительно проигрывает в гибкости
Очень поспорил бы. Если проект реализуется веб-разработчиком, а не самим клиентом, веб-разработчику бывает куда проще именно типизированный подход.
> Я таких очень давно не видел, но знаю, что они есть.
А у меня таких заказчиков большинство.
> Я считаю, что вынесение хидера-футера в отдельные шаблоны — порочная практика.
Стоп, стоп! Вынесение не в шаблоны, а чанки, то есть кусочки HTML-кода. И зачем куча открывающих тегов. Чанк в нормальных шаблонизаторах вызывается односложной конструкцией. И здесь вопрос прежде всего в решении проблемы различия вёрстки от страницы к странице. Например, для технических и одиночных страниц (сингл-враппер) шаблон может быть таким (QuadBraces):
Шаблон же товара уже будет вот таким, например:
Притом, в чанке side может быть определена логика показа блоков не просто на той или иной странице, а на том или ином типе страницы (в моей CMS, кстати, которую я сейчас завершаю, это определяется, т.н. филдсетами).
То есть я о вёрстке, а не о выводе как таковых данных. Поехали дальше =)
> Я не буду снобствовать и доказывать, что у серьезных пацанов иначе — никак
Это о предположительно паре десятков строк?! Вы шутите? Писать модель-контроллер ради функционала, который пишется на коленке и сломаться не может по определению, поскольку там просто нечему ломаться? Вы меня, конечно, простите, но я бессменно уже несколько лет ржу в голос над такими «серьёзными пацанами», которые ради пары действий плодят килобайты, а то и десятки килобайт говнокода; которые ради того, что можно сделать вообще статикой подключают массивные фреймворки. О дальнейшем развитии проекта хотите спросить? А вот как раз здесь нужно думать, где стоит утягивать пол-гитхаба под проект, а где достаточно наговнокодить пару десятков строк.
> Обычно под повторным использованием подразумевается немного
> другое — когда для реализации отличий в поведении не нужно копипастить
> код целиком и править нужное место, а достаточно передать необходимые
> параметры.
То, что Вы сейчас описали — это базовая парадигма функционального программирования. Пишем функцию и используем её, передавая каждый раз разные параметры. Повторное использование кода — это когда мы используем один и тот же код, подключая его из разных мест. Условно говоря, на хостинге лежит библиотека, а мы её подключаем в проекты из разных мест. Насчёт несущественности экономии места — расскажите это владельцам аккаунтов на шаред-хостингах, которые держат по десятку магазинов. Ога, для них ващщщщщще несущественно иметь 50 мегабайт вместо 5. Особенно когда на аккаунте не больше пары гигабайт вместе с базой и почтой. Так что такой подход как раз очень даже существеннен, если без сарказмы. Кстати, ещё немного похвалюсь будущим своим продуктом. У меня реализована концепция динамического репозитория, когда в проекте можно не только использовать код общего ядра, но и, скажем, переопределять базовые классы системы.
А наш с Вами диалог, однако ж, обретает всё большую конструктивность =)
Хм… Интересно, сколько весит Ваша система в итоге?
«Простой каталог и анкетирование приходится говнокодить независимо от платформы»
Кхм-кхм! Каталог в том же MODX делается без кодинга вообще. Создаём TV-параметры, цепляем их к шаблонам товаров, создаём товары — profit! И для того, чтобы показывалось, нужно просто воткнуть параметр (несколько символов) в нужное место шаблона. Я говорю не о шаблонах, о обработчиках, которые реализуют, скажем, логику каталога, добавления туда товаров, работы с товарами и т.п… Но коли уж Вы оговорились, что кодинг в Вашей системе нужен только для реализации специфичного поведения обработчика, то ОК, посмотрим на практике.
«А у вас работа с любой системой, где нету чанков, вызывает нервный тик? У некоторых вот нервный тик случается от хранения кода в БД»
Именно поэтому я в своё время разработал парсер QuadBraces (поищите, есть на хабре), который работает с файловой системой, а не с БД. А нервный тик у меня вызывает система, в которой логика шаблонов бесструктурна и непрозрачна. Например, у меня будут общие для всех страниц хедер и футер. А контент будет отображаться в зависимости от шаблона. И не свитчами в одном файле, а именно чанками.
Это в «хомяках» достаточно одного шаблона. А, скажем, в интернет-магазинах уже нужно будет порядка десятка разных шаблонов.
«Если никуда не спешить, можно PHP-код разделить на модель+контроллер»
Ради того, чтобы дёрнуть с партнёрского сайта крохотную XML-ку и вывести информацию из неё в какое-то место сайта, плодить контроллеры и модели? Жуть какая!
Повторное использование кода, кстати, это очень актуальный вопрос. Допустим, у меня есть десять проектов на одной и той же CMS. Как у вас обстоят дела с повторным использованием кода ядра CMS, дабы не хранить его в 10 экземплярах на хостинге?
Вижу, contenteditable. Если попробовать поработать с Вашим продуктом, скажем, в том же «ослике», оно будет работать? Вы уверены? А если пользователь захочет изменить дизайн, к кому он должен обращаться — к Вашей компании или к любому программисту? Насколько легко осваивается создание/кастомизация шаблонов для Вашей системы?
«добавление нового типа данных и, по необходимости, сопутствующей логики (пример: «Вакансия»);»
«Да, добавлять поля к существующим моделям и создавать новые модели можно. Это делается прямо в браузере. Новые поля сразу появятся в соответствующих формах. Для их обработки придется дописывать код моделей/контроллеров, а для отображения — править код шаблонов.»
— Дрынц! — сказала электропила.
— Ага! — сказали суровые сибирские мужики и пошли дальше валить лес топорами.
То есть для того, чтобы банально сделать анкетирование на сайте или простой каталог, нужно нагов… накодить ещё пару килограммов кода? Именно поэтому я и советовал ещё раз пристально изучить MODX (притом именно Evolution, к Revo у меня самого масса претензий). Добавляем в Evo TV-параметр к шаблону и дело в шляпе. Он отображается в форме ресурса, прекрасно создаётся/сохраняется в базе и, если вывести переменную в шаблон, отображается. В сущности и кодить почти не приходится. А создать простейший фильтр на TV-шках — дело минут десяти и пары десятков строк кода в простом сниппете.
«Скажу только, что во многом именно благодаря впечатлению от «чанков-сниппетов-тэвэшек» и «легко запоминаемых» комбинаций плюсиков-звездочек-скобочек-тильдочек в нашем шаблонизаторе осталось всего две синтаксических конструкции для вывода переменной»
Минуточку, а сама по себе концепция чанков у Вас реализована? Или написание шаблона под Вашу систему схоже с написанием шаблона под «неназываемую-от-которой-нервный-тик»? А сниппеты? Мне вот нужно вывести какую-то простейшую информацию с сайта друга, которую я дёргаю при помощи curl. Мне для этого нужно писать целый модуль?
2. Подход полного WYSiWYG безусловно удобен для пользователя. Беда в том, что в итоге получается едва ли не как в MS Word. Там тоже можно страницы создавать. Вот только по итоге там столько мусора в итоге оказывается. Проблему избыточности генерируемого WYSIWYG-кода решили? Пользователю, конечно, не нужна программная архитектура, но в большинстве случаев владелец сайта либо разбирается в базовых принципах веб-программирования, либо поручает это специально нанятому веб-мастеру.
3. Как обстоят дела с масштабируемостью данных? Допустим, есть пользователи. Каким образом, если это вообще возможно, добавлять дополнительные поля БЕЗ лишних тонн… программного кода? Тот же вопрос про дополнительные поля страниц и дополнительные модели.
Резюмируя сказанное прежде всего хочу отметить, что в большинстве случаев заказчик сайта доверяет дело программисту/веб-разработчику/вменяемому (или не очень) фрилансеру, не заботясь о стилях. Системы, ориентированные исключительно на пользователя, уже создавались. Ничего хорошего из этого не вышло. Взять хотя бы «джумлу», от одного упоминания о которой у меня начинается икота и нервное дёргание глазиком. Заказчик заказывает сайт разработчику, и его не заботит, что к чему. В качестве примера изучите MODX Evolution. Это как раз система, которая и для пользователя удобна и программисту доступна и удобна.
Общий тезис: реклама должна быть ненавязчивой и гармонично вписываться в проект. Тогда и блокировщики начнут отмирать.
Если каждый элемент массива, являясь в свою очередь массивом будет содержать, скажем, элементы с ключами id, title, desc, то итератор (в промежуточной стадии) выведет следующее:
Замечу при этом, что парсер по прежнему кушает совсем немного =)
И спасибо за идею ;)