Форумы / National / Russian / Идеи / Chunks

12345>>>

Куски кода в шаблоне

Dr2005alex
#1 31.08.2014 17:07

Привет всем! По своей работе приходится работать с другим движком. В нем многое подчеркнул, того чего хотелось бы иметь в cotonti.

К примеру можно организовать Chunk и в шаблонах. Куски шаблона в отдельных файлах, но с более удобным вызовом. Да я знаю что можно просто подключать любые файлы в tpl шаблон типа {FILE "{PHP.cfg.themes_dir}/{PHP.cfg.defaulttheme}/inc/head.user.tpl"}, НО можно ведь повысит узабилити?

Намного удобнее будет писать в шаблоне вызов chunk как тега к примеру {CHUNK.HEAD.USER}  а чанки хранить в отдельной папке в шаблоне.

Я уже тестирую свой вариант правки cotamplate.php добавил всего одну функцию..

В дальнейшем можно сделать редактирование чанков из админки и общих tpl файлов. 

Что думаете поэтому поводу?

WebKaa.ru - Cotonti Relax
esclkm
#2 31.08.2014 18:28

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

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Dr2005alex
#3 31.08.2014 18:55

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

WebKaa.ru - Cotonti Relax
esclkm
#4 31.08.2014 19:32

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

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

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

 

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

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

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Dr2005alex
#5 31.08.2014 19:54

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

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

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

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

 Согласен, но вот от кого это ждем?

Нужно самому разбираться и делать. Педлагать варианты. 

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

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

 

WebKaa.ru - Cotonti Relax
Yusupov
#6 01.09.2014 04:52

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

Dr2005alex
#7 01.09.2014 06:33

Так вот я и клоню к тому, что пора уже двигаться в этом направлении. Мне тоже очень понравились фишки редактирования языковых пакетов, конфигурации сайта и подгрузка шаблонов и плагинов прямо из админки.... это очень хороший показатель. Давайте двигаться в этом направлении... Админка у нас сейчас на низком уровне.

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

Так-же надо сделать кучу стандартых фишек для легкого редактирования шаблона сайта или его элементов. Как пример очень необходим механизм создания меню для сайта с добавлением\удалением его элементов. Чтобы пользователь с минимальными знаниями и не зная кода движка мог это сам сделать. А не искать какой путь писать и т.д.

WebKaa.ru - Cotonti Relax
Отредактировано: Dr2005alex (01.09.2014 06:40, 9 лет назад)
Macik
#8 01.09.2014 07:18

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

#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 файлах — вероятность уронить всю систему просто сохранив «битый» файл. Резоннее писать отдельный плагин, через который переопределать переменные и хранить данные в базе без изменения физических файлов

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Dr2005alex
#9 01.09.2014 07:51

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

 Да они есть, но в том виде что они сейчас их использование крайне не удобно. Я лично ни разу не использовал. Почему? а никакого узабилити.Мне проще этот кусок закинуть в файл. Потому что, как не крути туда вставляешь код уже подготовленный в редакторе. А нужна некая стандартизация, некие шаблоны, чанки и т.д. 

Что я имею ввиду? Мы к примеру можем использовать чанки в том варианте что я предложил. А их уже можно вставлять в слоты. Или сделать механизм работы со слотами. А так как есть сейчас не удобно.

Повторюсь... 

Я дописал обработку тегов чанков в шаблонизатор и создал папку chunk в шаблоне (место нахождение папки фиксированное, и работа в ядре не нужна.). Там можно накидать варианты кусков кода шаблона. менюшки, кнопки, формы и т.д. или целые части. А в основном шаблоне уже вставлять теги чанков.

Как вариант можно для слотов прикрутить селекторы чанков. Тоесть выбрал слот меню, а в списке рядом выбрал понравившийся чанк менюшки... и по аналогии с осталным.  

 

WebKaa.ru - Cotonti Relax
esclkm
#10 01.09.2014 09:39

Этим летом я встретился с 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. Слоты меню  - это то, что нуждается в ликвадации. ИМХО. Дело не в их удобстве. А в том, что вы сами через месяц забудите, что для какого слота писалось. Его имя ничего не отражает.

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Dr2005alex
#11 01.09.2014 09:59

Мда....  спасибо всех "оставшихся" за мнение. 

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

чанки можно оформить в любом виде... это был всеголишь вариант...

я думаю на этом все и встанет.....

Я согласен что для программиста котонти хорош... А для кого делают сайты? Ну сделаешь ты себе (как программист) пару сайтов. А если для заказчиков?

Многие, по крайней мере у меня, отказались от котонти.. знаете почему?  Боятся, что если меня не будет на связи, то они ничего не смогут сделать с сайтом. А если вообще исчезну.... то вообще поолный ппц. Нет ни доков, ни уроков, ничего нет кроме движка. И на форуме ответов ждут по несколько недель...

WebKaa.ru - Cotonti Relax
esclkm
#12 01.09.2014 10:18

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

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

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

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

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

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

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

littledev.ru - мой маленький зарождающийся блог о котонти.
снижение стоимости программирования и снижение стоимости производства разные вещи. Первое можно скорее сравнить с раздачей работникам дешевых инструментов, чем со снижением зарплаты
Yusupov
#13 01.09.2014 11:09

Я согласен что для программиста котонти хорош... А для кого делают сайты? Ну сделаешь ты себе (как программист) пару сайтов. А если для заказчиков?

Многие, по крайней мере у меня, отказались от котонти.. знаете почему?  Боятся, что если меня не будет на связи, то они ничего не смогут сделать с сайтом. А если вообще исчезну.... то вообще поолный ппц. Нет ни доков, ни уроков, ничего нет кроме движка. И на форуме ответов ждут по несколько недель...

Подтверждаю. Мой опыт также показывает, что Cotonti идеально подходит исключительно для своих собственных проектов, а не для проектов Заказчиков. Если вы не можете гарантировать им, что без вашего участия все будет в порядке, то лучше честно и откровенно им об этом сообщить. Сэкономите уйму времени и избавите Заказчиков от головняка, когда вас не будет рядом. Заметьте, веб-студий, которые создают Cotonti-проекты на заказ можно пересчитать на пальцах! Ито это даже не студии, а отдельные люди. А это существенный показатель, который говорит, что этот движок создавался не для рынка, а для собственных проектов, для хобби. 

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

Возвращаясь к исходной теме, можно тогда предположить, что чанки лучше реализовывать в виде отдельного модуля. Это позволит использовать их только на тех проектах, где они наиболее востребованы и их использование рационально. То же самое касается и редактора файлов. Если его реализовывать (и если это в принципе реально), то тоже в виде отдельного модуля. Остается вопрос в том каким образом это собственно рализовать. 

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

Отредактировано: Yusupov (01.09.2014 11:26, 9 лет назад)
Dr2005alex
#14 01.09.2014 12:17

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

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

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

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

WebKaa.ru - Cotonti Relax
Macik
#15 01.09.2014 12:35
#39708 Dr2005alex:

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

 Да они есть, но в том виде что они сейчас их использование крайне не удобно. Я лично ни разу не использовал. Почему? а никакого узабилити.Мне проще этот кусок закинуть в файл. Потому что, как не крути туда вставляешь код уже подготовленный в редакторе. А нужна некая стандартизация, некие шаблоны, чанки и т.д. 

Что я имею ввиду? Мы к примеру можем использовать чанки в том варианте что я предложил. А их уже можно вставлять в слоты. Или сделать механизм работы со слотами. А так как есть сейчас не удобно.

Повторюсь... 

Я дописал обработку тегов чанков в шаблонизатор и создал папку chunk в шаблоне (место нахождение папки фиксированное, и работа в ядре не нужна.). Там можно накидать варианты кусков кода шаблона. менюшки, кнопки, формы и т.д. или целые части. А в основном шаблоне уже вставлять теги чанков.

Как вариант можно для слотов прикрутить селекторы чанков. Тоесть выбрал слот меню, а в списке рядом выбрал понравившийся чанк менюшки... и по аналогии с осталным.  

Да, я понял, что ты сделал. Я о том, что это получается решение узкопосталвнной задачи, причем с созданием дополнительных сущностей. Получается частичное решение проблемы — мы городим огород и не решаем основных задач. 

Я не говорю о текущем варианте слотов, как замены. Я говорю о расширении/изменении/использовании принципа механизма слотов с учетом различных пожеланий.

 

Давайте определимся с задачами которые в целом решает абстрактный (пусть основанный на МодИкс) механизм чанков:

  1. Дать возможность администратору настраивать определенные блоки сайта редактируя куски шаблонов (чанки)
  2. Использовать регулярный синтаксис шаблонов внутри чанка (обработка вложенных блоков и тегов)
  3. Иметь возможность простой вставки чанка в текущий шаблон (вызов по имени)
  4. [в перспективе] иметь возможность вызвать чанк с параметрами

Что мы хотим иметь в дополнение:

  1. Возможность брать содержимое чанков из файлов 

 

Что нам дает принцип «слотов»: 

  • возможность хранить чанки в БД с автоматической загрузкой внутри скрипта (нет лишних обращений к файлам)
  • возможность включать в шаблон произвольный блок указав по его имени (п.3)
  • возможность редактировать содержимое через админку (п.1)
  • [с небольшим дополнением] использовать регулярный синтаксис шаблонов внутри чанка (п.2)

Чего ему не хватает:

  • возможности загружать содержимое из файла (решаемо на уровне плагина)
  • вызывать чанк с параметрами (но тут и твой вариант не катит, т.к. потребует изменения CoTemplate, о чем смотри ниже)

Узкие места:

  • в текущей реализации слоты грузятся заранее и парсятся в определенной точке скрипта, что делает не возможным использовать внутри них некоторые определенные в шаблоне теги (это опять же решается — тоже смотри ниже о CoTemplate)

 

Как я вижу (условный итоговый) вариант/алгоритм:

  • основные данные чанков хранятся в системном конфиге 
  • имя и содержимое чанков может быть изменено 
  • содержимое чанка парсится как включаемый шаблон
  • содержимое ченка вставляется в основной шаблон по вызову определнного вида тега (например {CHUNK.GROUP.SUBGROUP.CUSTOM_NAME}) 
  • чанку можно задать переменные (тут надо думать как, возможно так же расширив и стандартный метод для передачи нескольких параметров)
  • загрузка файлов реализуется либо прямым выбором в админке при настройке чанков (примерно как ты расписал), либо автоматически (фолбеком, если чанка с таким именем нет). 

 

«О CoTemplate»

Кроме прочего, если уж опять «расширять» CoTemplate, то я бы приделал универсальный механизм, позволяющий расширить шаблоны произвольным синтаксисом, за счет вызова сторонних функций. Т.е. сторонний плагин регистрирует в классе маркеры (метки) которые он хочет парсить и назначает на их обработку свои функции, а шаблонизатор при обработке шаблона проверяет список зарегистрированных, и при необходимости вызывает указанные функции отдавая содержимое тега. Тогда расширение шаблонизатора, в случае необходимости будет как раз-два.

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F

12345>>>