Foren / National / Russian / Идеи / Chunks

не вижу смысла в данном решении) Если честно... хотя модиксе чанки удобны.

Что в данном решении стандартизованного?

зачем вводить и менять шаблонизатор?

я просто так и не понял наверное.

мне например чаще не хатает множественных параметров для колбэк функций

и не хватает нормальных сообщений обошибках шаблона.

Чанки в реализации как в Modx очень удобны, поэтому если сделать аналогию для Cotonti, то это несомненно прибавит ему привлекательности. Но в первую очередь тогда надо продумать единый и безопасный механизм редактирования файлов через админку. Если будет такой механизм универсальным, то можно будет не только чанки создавать, но и легко редактировать ресурсы, языковые переменные, шаблоны, css, не говоря уже о создании собственных плагинов непосредственно через админку. 

Млин, писал пост а Хром грохнулся...

#39703 Dr2005alex:

Что в данном решении стандартизованного?

Мы в последнее время, как наверное всем видно, теряем людей. Но как ни странно и новичков особо тоже нет. Мое мнение что надо котонти немного упрощать в пониманиии кода. Особое внимание должно быть положено на шаблоны. Их НЕТ. Мне кажется что для новичка будет проще написать конструкци.  {CHUNK.HEAD.USER}  чем  {FILE "{PHP.cfg.themes_dir}/{PHP.cfg.defaulttheme}/inc/head.user.tpl"}. А стандартизация в том, что можно закрепить имена стандартных чанков. типа {CHUNK.MENU} и можно будет сделать библиотеку чанков меню. Таким образом новичек сможет поменять кусок шаблона просто поменяв чанк. Также в дальнейшем можно сделать редактор чанков или менеджер чанков. и т.д.

Буду краток —

Сама по себе идея интересная, у самого были аналогичные мысли. Но…

Напомню, что вопрос редактирования ресурсов через админку поднимался в различных вариантах не раз. Но всегда упирался в вопросы безопасности, а именно разрешений для скрипта писать файлы, точнее прав писать в определенные папки. Что есть потенциальная дыра в безопасности.

Так же напомню, что в Котонти уже есть зачатки механизма чанков — это «слоты меню». 

Объясню суть идеи: во-первых, надо сделать список редактируемым по количеству и названию блоков, во-вторых разрешить в тексте слотов использовать конструцкции шаблонов (блоки и теги), сделав их таким образом микрошаблонами.

Второй пункт уже был мной реализован в плагине «slots_n_tags». 

В данный момент,например, меня очень заинтересовал варианнт создания базового шаблона для котонти с генерацией css данных через PHP  http://portal30.ru/articles/ispolzovanie-php-v-css-fajlax

Это может помочь  с быстрым редактированием шаблона под себя, для новичка.Путем изменения констант. Можно и редактор замутить. Жаль что сообщество идет в сторону seditio..... и нет развития... на новичков наплевать... а ведь когда-то я тоже в первый раз все увидел. Обычные реплики это: "Нафиг это надо и т.д." Жаль... такой потенциал закапываем в землю..

Оно идет не в сторону Seditio, а как не прискорбно пока топчится на месте — каждый на коленке что-то делает под себя и для своих проектов, не обсуждая и не вынося результат на публику. То, что ты предлагаешь идеи это очень правильно. И то, что мы их здесь обсуждаем (какими бы жаркими не были споры) это хорошо.

По существу приведенной ссылки — на мой взгляд это перебор. Вопрос в эффективности и необходимости.

Вижу больше недостатков, чем пользы:

• усложняет код, как для понимания, так и для поддержки — соотв. увеличивается и вероятность ошибки.
• увеличивает накладные расходы на «лишний» вызов интерпретатора

Реальных случаев, когда это необходимо применить не вижу. Т.к. если изменения в CSS небольшие, то резоннее это сделать на стороне основного скрипта включив стили прямо в основной файл. Если изменения большие — лучше иметь несколько отдельных файлов (они могут компилится на этапе разработки), которые подключать в зависисмости от определенных условий. Если надо обязательно дать пользователю редактировать — вынеси в чанк/слот и включай в текст шаблона.

#39704 Yusupov:

Если будет такой механизм универсальным, то можно будет не только чанки создавать, но и легко редактировать ресурсы, языковые переменные, шаблоны, css, не говоря уже о создании собственных плагинов непосредственно через админку. 

Я бы все же разделил эту тему на отдельные, и задался вопросом кому, в каких случаях и как часто необходимо менять все эти ресурсы. Мое общее мнение, допускать пользователя (пусть и админа) к файлам это зло, и надо свести это к минимуму.

• Создание плагинов через админку — вообще не вижу смысла. Если админит человек способный написать и установить плагин ему можно и нужно дать права на запись плагинов в соотв. папку. А через админку это только лишний вариант уронить систему (проверки кода-то нет) без возможности восстановления средствами админки. В общем возьми генератор (раз или два) плагинов, нормальный редактор с проверкой синтаксиса PHP и вперед.
• Редактиорвать шаблоны вопрос опять же спорный. Я в целом за удобство, но уж очень много подводных камней — безопасность на запись файлов в целом, механизм замещения шаблонов (они и в папке plugins и modules и themes/ и ее подпапках), и т.п. В общем смотри выше про чанки.
• изменение CSS из админки — для чего? Если ты разработчик темы — отредактируй в номальном редакторе и залей. Если надо сделать механизм правки пользовательских стилей — вынеси его, например, в слот и подключай в текст страницы через `cot_rc_embed`.
• Единственная, имхо, уместная для редактирования сущность это ресурсы и языковые файлы, но и тут у нас зоопарк с «местом дислокации» этих файлов (опять безопасность на запись), а т.к они храняться в PHP файлах — вероятность уронить всю систему просто сохранив «битый» файл. Резоннее писать отдельный плагин, через который переопределать переменные и хранить данные в базе без изменения физических файлов

Этим летом я встретился с Trusmaster’ом в НН. Это была очень интересная продуктивная встреча в плане мыслей и познания.  Собственных идей и т.д. Давайте дружно признаем, что cotonti – это его проект. Но жизнь делает свои повороты. И у него есть семья, есть свои проблемы, которые надо решать. Cotonti стал для многих проектом, приносящим деньги. Для кого-то – это проект вдохновения.  Мы все растем и нас начинают привлекать разные идеи из разных движков.

Мне вдохновила недавно идея GRUB (пользовался ей в Yii 1.2)/ Я начал сразу же писать свой редактор GRUB на c# для Cotonti (даже пришлось написать свой шаблонизатор). Но еще больше мне понравилась идея моделей. Подобными вещами занимались Trustmaster и Alex300 несколько лет назад.

Я не предлагаю это вводить в ядро.

Я задумался давно на тему интерфейсов. И понял, какое это зло.

Давайте подумаем, что мы можем сделать для котонти? Те, кто еще в нем. Но не только это важно. Важно понять для кого мы работаем?

1. Для сверхконечного пользователя. Ему интересна, только генерируемая информация.
2. Для владельца сайта. Мы никогда ему не угодим. Время бесплатных CMS уже ушло. Люди сейчас платят большие деньги за готовые решения именно для них. Но никак не универсальную посудомойку-пылесос. А подобных инструментов, в котонти уж простите и в помине не водилось.
3. Для юного вебдзайнера, верстальщика. Мне кажется это именно та категория! Он может сделать сайт на котонти любой сложности ля любого клиента.
4. Для серьезных веб-разработчиков. Они наоборот предпочитают современные фреймворки. Да и любят они греметь словами MVC и другими. Хотя солнце можно нарисовать ручкой, песком, карандашом, красками и т.д.

Теперь про ЧАНКИ. Я с ними категорически не согласен.

Любая переменная в шаблонах используется как {A} или {A.B.C}. А Dr2005alex предлагает использовать имена файлов одинаково с переменными. Это ИМХО - просто дурной тон - создать множество интерфейсов. А это плохо. Мы легко понимаем, как пользоваться дрелью, так как в ней всего 1 кнопка.  Не надо делать 5 кнопок для одного действия – это вызывает отторжение. Купите дрель с пятью кнопками сверлить и тремя розетками. НО и не надо одной кнопке назначать 5 действий.

В котонти многие интерфейсы нуждаются в жестком упрощении. Но не усложнении.

ИМХО.

Мне не хватает сегодня:

- написанной одним дизайнером разумной админки и стартового шаблона на Bootstrap. Не просто впихивания бутстапа в базовый шаблон, а создание уникального проработанного шаблона.

- не хватает моделей. Если честно – хочется модуль страниц переделать. Никому не нужны функции импорта, сохранения, создания страницы. От них было бы больше току – если бы они работали внутри вменяемой модели страниц, в которой были бы расписаны все поля и все исключения.

- не хватает проверки форм при помощи JS.

- не хватает удобного редактирования нескольких страниц.

- не хватает колбэков в шаблонизаторе для нескольких параметров, например [cot_url | {A} | {B}]

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

-не хватает возможности генерировать шаблон из текста, а не из файла.

-не хватает документации. Любого качества.

- не хватает удобной админки с вменяемой логикой. Я не хочу попадать к одной ссылке 10ью путями! Это усложняет общение с клиентами.

-не хватает генерируемой под клиента админки.

- не хватает синхронизации с соц сетями.

- адекватной работы с файлами.

Я вижу много путаницы в интерфейсах.

- Стандартные модули и плагины имеют названия то во множественном, то в единственном числе: forums и page.

- файлы их пути и использование имеют различные названия. Например: cot_langfile или cot_incfile. Папки называются: plugins , modules, system – но внутри этих функций мы используем plug, module, core

- имена установщиков, апдейтеров, унисталяторов – еще 1 путаница.

-обращение к конфигам  и auth модулей и плагинов крайне различно.

И таких путаниц уйма. И во многих из них виновен я. Но уже это есть.

Я многие свои приложения размещаю на github и там много решений поставленных вопросов. Просто реально – вопрос стоит так: а что мы хотим и для кого мы это делаем. Спасибо, что не поленились прочесть.

Добавлено 1 минуты спустя:

P.S. Слоты меню  - это то, что нуждается в ликвадации. ИМХО. Дело не в их удобстве. А в том, что вы сами через месяц забудите, что для какого слота писалось. Его имя ничего не отражает.

я знаю эту фишку. 

но есть хуже фишка, которую не осознают заказчики:

- у каждого додика своя методика.

Даже если они возьмут БИТРИКС - они все равно будут привязаны к программисту.

Я за развитие котонти. но надо наметить пути его развития. которые устроят всех. Все равно у каждого из нас свое наследие.

А если работать с конечным заказчиком -ему нужен удобный продукт.

Тут ответило 4 человека. Вот и считайте, что это комманда котонти. Я за работу. но что и как мы тянем?

Вот смотрю многим чего-то не хватает в котонти. Кто что может начать развивать? Я за узабилити движка. Основное в нем уже есть и очень хорошее. Нужно сделать типа как подключаемые навесы для узабилити. Программеру они будут не особо нужны, а для конечного пользователя, будет хорошим тоном. Те же чанки попробую релизовать плагином или модулем. Давайте расставим пункты необходимого.

Добавлено 1 минуты спустя:

- у каждого додика своя методика.

Нету цели угодить каждому додику, но нужно иметь хотябы стандартные вещи в инструментах.