LINUX.ORG.RU

Ответ на: комментарий от bvn13

О да, на PHP - JSON'овские API, на каком нибудь там React'е - фронтенд. По мне так ужас, но с достаточно сложными и сильно посещаемыми сайтами - единственный нормальный выход.

anonymous ()

Или mvc это панацея? У меня сейчас и html и логика в одном файле.

mvc — это концепция. Ты спрашиваешь можно ли использовать концепцию не используя концепцию?

пишешь html-шаблон, сохраняешь в файл, например (схематично):

<html>
  <title>%title%</title>
  <table>
    %table_content%
  </table>
</html>

потом пишешь логику:

<?php
  function get_table_html() {
    ...
  };

  var $template = file_get_contents('template.html');
  $template = str_replace($template, '%title%', 'Hello MVC!');
  $template = str_replace($template, '%table_content%', get_table_html());

  echo $template;
>

pihter ★★ ()
Ответ на: комментарий от goingUp

Переходи на фреймворк, например laravel

никогда не понимал смысла усложнять себе жизнь: на php и так все в два счета кодится, нахрена загонять себя в рамки фреймворка?

pihter ★★ ()
Ответ на: комментарий от dimuska139

Почему ужас? Удобно же

объясните мне, зачем нужны реакты, вебиксы и прочие ангуляры, когда есть jQuery? вебморду к железяке с использованием этих вот написать дольше, чем руками на js

pihter ★★ ()
Ответ на: комментарий от pihter

Смотря насколько сложная веб-морда. Я за весь свой опыт разработки (почти 10 лет) ни разу не видел кода на jQuery в состоянии, пригодном для поддержки. Потому что когда ставится задача «хочу после сабмита формы, чтобы попап-окно оставалось все равно открытым, сохранялись фильтры таблицы, сортировка, а,да, и вот этот переключатель должен быть включенным, а еще покажи мне индикатор загрузки», то ВСЕГДА код с jQuery-лапшой превращается в кал, который сопровождать невозможно. Да, логично при сабмите формы делать аякс-запрос, тогда, казалось бы, проблема решится, но нет, потому таких форм может быть много, а часть их полей тоже подгружается аяксом. Код сайтов на jQuery всегда оставляет желать лучшего. Особенно, когда на сайте много кнопок, формочек, окошек, фильтров и прочих интерактивных элементов.

Также если твой сайт на jQuery, то отдать фронтенд-разрабам весь фронтенд в работу очень запарно, потому что так или иначе им все равно придется возиться с кодом бэкенда, прописывать data-атрибуты и т.п. html-элементам - это неудобно. А если ты пилишь сайта на Angular/React/Vue, то у тебя фронтенд связан с бэкендом только интерфейсом API - и все.

А CRM на jQuery пробовал сделать? Если нет, то попробуй. А потом попробуй на Angular/React/Vue - поймешь разницу.

dimuska139 ()
Ответ на: комментарий от pihter

Кодится в два счета что? Говнобложик из пары страниц - возможно. Тестами такое покрыть сможешь? Замокать запросы к базе и т.п.? А так фреймворки очень сильно сокращают количество кода и сил, затраченных на разработку. Многие из разрабов них не знают и не используют шаблоны проектирования, и их код потом невозможно поддерживать или хотя бы тестами покрывать. Фреймворк им дает каркас, в рамках которого они могут писать более-менее структурированный код на любимом пэхапэ. Лучше будут пусть загнаны в рамки фреймворка, чем будут писать код, от которого из глаз будет потом кровь идти.

P.s. Тем более, что если микрофреймворки типа php slim, которые тебя ни в какие рамки не загоняют.

dimuska139 ()
Ответ на: комментарий от pihter

на php и так все в два счета кодится, нахрена загонять себя в рамки фреймворка?

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

goingUp ★★★★★ ()
Ответ на: комментарий от pihter

за тем же, зачем и был создан сто лет назад — придать JS-у человеческий вид

Только получается всегда неподдерживаемая параша, которая ещё тормозит по сравнению в vanilla.

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 1)

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

Infra_HDC ★★★★★ ()

У меня сейчас и html и логика в одном файле.

Вам с таким подходом в wordpress.

Или mvc это панацея?

Вариантов разделения масса. Можно и самому что-то придумать. Советую ради любопытства посмотреть на устройство anchor cms и laravel.

EmgrtE ★★★ ()
Ответ на: комментарий от pihter

В моём фреймворке при сборке шаблон компилируется в функцию. Из шаблона "foo <%= @user %>", например, получается функция с примерно таким телом (псевдокод):

arg0 = to_string(fetch_assign("user"))
return "foo " + arg0

В преимущества помимо скорости рендеринга (у тебя, например, для каждой подстановки str_replace проходит целиком весь текст шаблона) входит поддержка выражений, управляющих структур (условий/циклов), также данное решение не подвержено XSS.

theNamelessOne ★★★★★ ()
Ответ на: комментарий от dimuska139

Вроде бы основные поисковые движки уже могут выполнять JS при индексации, главное, чтобы страница со скриптами не слишком медленно грузилась.

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

Только Гугл, и то такие сайты он индексирует хуже обычных. Поэтому SSR лучше юзать. К тому же без этого, скорее всего, всякие шарилки в соцсети не будут нормально работать (но это уже не точно).

dimuska139 ()
Ответ на: комментарий от EmgrtE

А как же не переусложнение тогда? Отдавать html с сервера средствами laravel/django, а на фронте разводить jquery-лапшу? Не сказал бы, что это чем-то лучше. Тем более, что ssr для React-сайта прикручивается подключением NextJS и запуском одного js-файла - это ж просто.

dimuska139 ()
Ответ на: комментарий от theNamelessOne

В моём фреймворке при сборке шаблон компилируется в функцию

в твоем — это который ты используешь или который ты написал?

В преимущества помимо скорости рендеринга (у тебя, например, для каждой подстановки str_replace проходит целиком весь текст шаблона) входит поддержка выражений, управляющих структур (условий/циклов)

я не имел в виду что нужно делать как у меня написано, я хотел показать что можно выполняя код на php сформировать html-код для отдачи клиенту на основании данных шаблонов, фазы луны, данных из БД. PHP затем и придумали. Не обязательно делать сто раз str_replace, я просто показал самый простой и очевидный способ разделить представление и модель. Вы так буквально поняли, как маленькие.

то что ты показал — вариация на тему, что я и пытался доказать (по-другому ты не сделаешь), а именно берем данные шаблона и БД и формируем код. Имхо, изобретать на шаблонизаторе html шаблонизатор html в то время как и первый хорошо шаблонизирует html — неверно.

// другой вариант действительно есть — это вот эти вот ваши реакты и на сервере оставить только json-api. но тут, имхо, и ПХП не нужен

также данное решение не подвержено XSS.

даже то, которое я предложил, не подвержено если

1) не позволять попадать в заменяющие переменные данным пользователя (в ряде случаев — более чем)

2) в пыхе были какие-то функции (но я уж позабыл их имена) через которые строго рекомендуется пропускать пользовательские данные перед выводом в выхлоп специально от этого вот. Учат этому на первом курсе ПэХаПэ-шного училища

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

ЛОР вон на фреймверке написан или где? щас проверим атаку: <script>alert('LOR — шерето!')</script> гляди-ка — не работает...

pihter ★★ ()
Ответ на: комментарий от dimuska139

Отдавать html с сервера средствами laravel/django, а на фронте разводить jquery-лапшу

а тебе какая разница разводить jquery-лапшу или react-лапшу? нешто на реакте можно сдалать короче? что может быть короче, чем $('#buttonId').click(function(){ $('#panelId').hide(); }); ?

pihter ★★ ()
Ответ на: комментарий от static_lab

Привет, XSS!

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

Для пользовательского — есть функции экранирования. Опять же, можно подумать, в этих ваших фреймворках не так.

pihter ★★ ()
Ответ на: комментарий от pihter

в твоем — это который ты используешь или который ты написал?

Который я использую.

Не обязательно делать сто раз str_replace, я просто показал самый простой и очевидный способ разделить представление и модель.

Кривой, тормозной, дырявый.

то что ты показал — вариация на тему, что я и пытался доказать

Естественно, это не так.

не позволять попадать в заменяющие переменные данным пользователя (в ряде случаев — более чем)

То есть большинство реальных приложений (сложнее хелловорлдов) сразу отсекаются?

в пыхе были какие-то функции (но я уж позабыл их имена)

Божечки-кошечки…

это не пользоваться фреймворками, которые не только не позволяют стрелять по ногам, но и работать (алсо, утежеляя и усложняя все в сто раз)

Если фреймворки тебе мешают работать, может, дело не в фреймворке?

а научить людей писать прогаммы

…кривые, тормозные, дырявые.

theNamelessOne ★★★★★ ()