Есть ли такие реализации на PHP когда в одном файле пишется js, html, css, php, а движок разделяет их и выплевывает пользователю?

Question

[lihtenshtein]

В общем нужда такая. Представим, что нам необходимо написать компонент для проекта на php. Этот компонент выводит, например, маленький div блоки с информацией о футбольной команде. В этом div есть статическая информация, есть какие-то интерактивные элементы, например кнопочка "Подписаться на новости команды".

Соответственно, нам бы хотелось вставлять этот компонент в проект в любом из шаблонов проекта (предположим используется шаблонизатор Smarty) как-нибудь так:
{SomeCMS::include_component('footbal_command_info', 'command_id:17');}

А сам компонент это один только файл где-то в дереве проекта, в котором описывается и css, и js, и html верстка, и логика php. CMS'ка при подключении данного компонента выделяет из него css, js, html, получает данные из БД согласно логики описанной на php и отдает клиенту страницу. И для клиента выглядит все так, будто я отдал ему среди прочего три файла:
footbal_command.js
footbal_command.css
index.html - в котором где-то глубоко есть блоки с фотбольными командами.

Есть ли такие CMS, возможно библиотеки, или возможно кто-то знает как этот подход называется. Подойдет любая помощь!

MVC - хорошо, я знаю. Но есть нужда именно в таком подходе.

Спасибо.

Answer 1

[Сергей Протько]

Такой подход называется "говнокод".

Вот вам пример:
пишите вы такой в php файле (внезапно) css стили например. Проблемы которые могут возникнут:
- расширяемость. Что бы поменять стили нужно лесть в какой-то файлик и разбираться. При этом в этом файлике содержится логика, и шаблоны и все на свете.
- автокомплит - на все IDE будут радостно подставлять вам значения и автодополнять селекторы.
- инструменты сборки типа autoprefixer, uglifycss и т.д. впилить будет проблематично. Так же в огромными кастылями придется вклинивать тот же livereload.

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

Можно реализовать на twig-е и добавить в этап компиляции шаблонов мега сложную логику, которая будет отслеживать вывод переменных, кешировать запросы для выборок и использовать их. Все инлайн стили и скрипты при этом будут выдираться (если только явно не попросили их оставить) и сохраняться в кэш. Это единственный интересный вариант, который худо-бедно приемлим. Но он крайне сложно реализуем.

Уж извините, но то что вы не пользуетесь IDE и вам лень держать все в разных файлах - это ваши проблемы.

Comments

[lihtenshtein]

Спасибо, ваш ответ понятен. Проходим мимо )

Answer 2

[KOLANICH]

А сам компонент это один только файл

А что мешает использовать папку? Если нужно распространять одним файлом, что мешает использовать архивы?

Comments

[lihtenshtein]

Не удобно открывать в редакторе 5 файлов для правки одного компонента. И потом есть определенные бонусы, когда все в одном файле... проблема неймспейсов может быть хорошо решена одним махом в css, js, php... Разработка удобней ну и т.д...

[KOLANICH]

@lihtenshtein А зачем тогда разделять? Пусть и грузятся как один файл, быстрее будет, чем если браузер будет делать по несколько запросов

[lihtenshtein]

Да, но если я пишу компонент, например товарчика, а на странице у меня есть 10 мест где этот компонент должен показаться, то мне css нужно заиметь желательно в header'е, ну или в одном месте каком-нибудь... Понимаете?

[KOLANICH]

Так делайте в несколько файлов. Пишите в одном, потом разбейте на несколько. Хотя мне удобнее в нескольких. Можно сделать загрузку css в head через js, но зачем?

[lihtenshtein]

)) В общем понятно. Вы React от Facebook видели?

[KOLANICH]

Ещё можно сделать текстовый файл специального формата и бить при установке на несколько... Неудобно это.
Советаю делать по-нормальному, иначе геморрой в медицинском смысле от долгого сидения над распутыванием геморроя другого рода обеспечен.

[KOLANICH]

Теперь видел. Не одобряю.

[lihtenshtein]

Вот и зря. Не думаю, что MVC будет жить вечно. Ему осталось не долго.

[Сергей Протько]

@lihtenshtein, воу воу, какие серьезные у вас высказывания. Любопытно что придет на смену MVC/MVVM и прочим приблудам современных подходов к разработке.

[lihtenshtein]

Не знаю как это будет называться, но одно знаю точно - мне тесно и неудобно в MVC.

[Сергей Протько]

@lihtenshtein мне кажется у вас либо недостаточно опыта, либо вы просто не работали с большими проектами и в больших командах.

[lihtenshtein]

@Fesor нет, ошибаетесь. Вы слышали про React от Facebook или вообще про реактивный подход в программирования на js в UI?

[Сергей Протько]

@lihtenshtein это ТОЛЬКО UI. То есть только буквочка V в составе MVC.

[Сергей Протько]

@lihtenshtein не будете же вы бизнес логику в шаблоны пихать

[lihtenshtein]

@Fesor буду пихать за милую душу ))) Ладно, с вашего позволения оставлю этот диалог ) MVC - хорошо. Я написал это в посту. Не против его. Просто хотелось бы взглянуть на другой подход, если он есть.

Answer 3

[Viktor Vsk]

1) В чем смысл такой конспирации? Почему не написать и стиль и js инлайн? Так, кстати, будет и проще с подгрузкой элемента (никаких onload в js).
2) Почему не описывать такой блок тремя файлами: js, html, css. и подключать их соответственно при вызове в нужных местах?
3) Под ваше описание подходит метот yield в руби (www.tutorialspoint.com/ruby/ruby_blocks.htm). В Rails вы можете сделать что-то вроде:

<head>
<%= yeild :head %>
</head>
...
<body>
...
<div id="myBlock">
<%=  content_for :head { '<style>...</style>' } %>
</div>
</body>

Comments

[lihtenshtein]

Почему не писать в отдельных трех файлах - это вопрос, но думаю он тут не уместен. То, что это можно делать, я безусловно знаю. Интересуют фреймворки, которые позволяют описывать логику какого-то кусочка в одном файле! Все. Много кусочков, подключенных один в другом компилируются так, что пользователю выдается результирующая html страница + все кусочки css и js в одтельных файлах, которые подключаются в head.

[Viktor Vsk]

stackoverflow.com/questions/17483806/what-does-yie... вот что-то похожее в пхп

[lihtenshtein]

Нет, это немного не для этого. Вернее совсем не для этого.

[Viktor Vsk]

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

Вообще, формулировка какая-то сферическая. Очень долгое время задачи всех виджетов решает фронтэнд, зачем перекладывать это на сервер?

Answer 4

[Андрей Мацовкин]

Во-первых, как тут правильно сказали — мешать все в один файл это очень плохо с точки зрения последующей поддержки кода.
Во-вторых, на сколько необходимо, чтобы код отдавался именно отдельными файлами? Ведь можно, как правильно написал @victorvsk включить весь код в страницу «inline». Это и для загрузки быстрее будет.

В принципе оба эти подхода реализуемы в плагинах CMS Cotonti. И хотя его плагины это обычно несколько отдельных js/css/php файлов подключаемых для загрузки, но можно реализовать и «inline» подход.

Приведу кусок кода для обоих вариантов:
1. подключение раздельных ресурсов

cot_rc_add_file($cot_bootstrap['css_file']); // подключаем CSS файл в <head>
cot_rc_link_footer($cot_bootstrap['js_file']); // подключаем JS файл в конец страницы

2. использование включения прямо в код:

// вставляем CSS код в текущее место выполнения скрипта
cot_rc_embed(".my_red{ color:red; }", false, 'css');
// подключаем JS код в конец страницы
cot_rc_embed_footer("javascript_var = $current_timestamp; console.log(javascript_var);");