Переписать грамотнее и с помощью Laravel реально ли и каким лучше образом?

Question

EpIvIaK @EpIvIaK

PHP
Laravel

Переписать грамотнее и с помощью Laravel реально ли и каким лучше образом?

Приветствую. Тренирую Web потихоньку, PHP + HtmlCSS + JS. Друг (далёкий от темы) даёт задания (так как опытный пользователь сайтов), он мне просто помогает, придумывает задумки-сайты. Доделал вот один, там файлов 16-17 суммарно, в 6-7 (расширение .php) из них в перемешку php с html. Хотя я и делал echo <<< html END. Но показав сайт одному опытному человеку, он сказал, что всё же это недопустимло и вообще лучше на Laravel переписать это всё.
А так как я хочу это на ГитХабе держать и если что показать в будущем кому-то при надобности если что искать буду, то наверно не солидно оставлять это в этом изначальном варианте (стыдноватая смесь PHP c HTML, даже для первого более менее серьёзной пет-работы). И коль у меня цели это показывать в будущем по надобности наверно стоит на Laravel это переписать. Но там есть файл и на 1300 строк например.

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

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

Более наглядно (не буду копировать всё, а оставлю основное содержание), вот файл например:

<?php
Некоторые проверки, уточнения
}
echo <<<REG
    <!doctype html>
    <html lang="en">
    <head>
... тут всякие визуальные уточнения страницы; форма, css специфика для страницы.
<script> // тут всякие оперативные реакции на действия в браузере требуемые страницей.
            function validate(){
</script> 
REG;
?>
<?=require_once  $_SERVER['DOCUMENT_ROOT'] . '/public/footer.html';?> //- конец страницы.

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

Такие дела. =)

Вопрос задан 13 апр.
268 просмотров

11 комментариев

Подписаться 1 Простой 11 комментариев

Михаил Ливач @Mausglov

мне кажется, Вам ещё далеко до Laravel. Сначала стоит разделить в голове, что html+css+js - это фронтенд, а php - это бэкенд, де совершенно независимых области.
Потом решить, на чём Вы хотите специализироваться. Если фронтенд - то забудьте пока по PHP и качайте только его. Даже по показанному видно, что уровень у Вас ещё очень низкий.
<html lang="en">
Сомневаюсь, что Вы делали это для англоязычной аудитории.
<script>function validate(){...}</script>
Вы понимаете, что тут захламляете глобальную область видимости? Уверен, что нет. Изучите, что такое модульность и замыкания.
Предполагаю, что "за кадром" осталось ещё много подобного. Вы пока действуете по принципу "monkey see, monkey do" - это хорошо для получения хоть какого-то начального результата, но теперь нужно понять смысл написанного.
После этого я предлагаю Вам посмотреть на webpack и шаблонизатор Pug.
Если же хотите качать бэкенд - то Pug и webpack можно отложить. Вместо этого перечитайте справочник по PHP . ( А может, Вы это уже делали недавно? Тогда поздравляю, можно идти дальше ). Например, вот такое:
echo <<<REG
на мой взгляд, довольно бессмысленно. Была бы тут запись в переменную, тогда да. Проще было поставить закрывающий php-тег "?>" , а потом открыть в нужном месте.
Затем почитайте про паттерны проектирования ( они же - шаблоны проектирования ). Заучивать их сейчас не нужно, достаточно просмотреть и понять, что это. ( На том же сайте стоит прочитать раздел "Рефакторинг" , полезно).
Затем погуглить "PHP шаблонизаторы". Понять, что это такое.
Почитайте, что такое "Model-View-Controller" (MVC)
А уже после этого приступать к Laravel - так как это MVC фреймворк, построенный с ипользованием паттернов проектирования, и который в своём составе содержит шаблонизатор Blade .

Написано 13 апр.
EpIvIaK @EpIvIaK Автор вопроса

Михаил Ливач, спасибо большое за критику.

Вы понимаете, что тут захламляете глобальную область видимости? Уверен, что нет. Изучите, что такое модульность и замыкания.

Я правильно понимаю, что тут сводится речь к тому чтоб в отдельном файле js держать это? Т.е об этом речь?

Справочник PHP конечно мне знаком, но с другой стороны безусловно есть вещи ещё непроработанные. yield например и немало чего ещё.
Видимо и правда надо подойти так - прочитать его как книгу, а не пользоваться им по мере необходимости (что бывает часто).

Про echo <<< жаль, что так получилось. Я им пользуюсь не так давно и я понял логику о которой Вы (про смысл был бы если бы в переменную). Я понимаю о чём речь.
Почему же я так делал? Хотелось полумер. Говорили, что смешивать <?php?> html <?php?> html плохо, а тут вроде как в echo<<< я html код как бы интегрирую сразу в PHP пространство.
В общем вышло только хуже.

Да, надо мне с этим всем знакомиться, а то так и останусь на одном месте. Спасибо.

Написано 14 апр.
Adamos @Adamos

Михаил Ливач,
А уже после этого приступать к Laravel - так как это MVC фреймворк, построенный с ипользованием паттернов проектирования, и который в своём составе содержит шаблонизатор Blade .

И после всей этой небыстрой эволюции сунуться в реальный мир и обнаружить, что динозавры к этому времени уже вымерли и сайты давно делают не на бэкенд-шаблонизаторах, а на реактивных фреймворках, используя Лару только как API.

Написано 14 апр.
Adamos @Adamos

EpIvIaK, вам стоит попробовать "забыть все, что учили до этого" и нырнуть в Ларавель. Будет непросто, но есть шанс, что вы все-таки, подчиняясь канве этого фреймворка, обойдетесь без заучивания ошибок прошлых поколений и освоитесь с нормальным разделением кода. Потом почитаете правильные книги, подтянете теорию - зачем все это нужно. Уже понюхав пороху, хотя бы и на самом ламерском уровне.

Написано 14 апр.
Михаил Ливач @Mausglov

EpIvIaK,

Я правильно понимаю, что тут сводится речь к тому чтоб в отдельном файле js держать
это? Т.е об этом речь?

Нет. Разделение HTML и JS в разные файлы хорошо, но это другое. Название функции validate заставляет предположить, что Вы там проверяете пользовательский ввод. Аргументов функция не принимает ( по сигнатуре). Что Вы будете делать, когда появится ещё одна форма на странице, с совершенно другим содержимым? Или, более наглядно: допустим, у Вас уже есть эта другая форма на другой странице, и тоже есть функция validate() , но с другими проверками. Вы решили эту часть с формой продублировать на первую страницу. Понимаете, что произойдёт?

Короче: если функция нужна только форме, зачем её пихать в глобальную область видимости ( == делать полем объекта window) ? Переделайте в function expression и засуньте в анонимный обработчик для события DOM Ready. Обработчик замкнёт контекст, и будет хорошо.

Написано 14 апр.
Михаил Ливач @Mausglov

EpIvIaK,

Говорили, что смешивать <?php?> html <?php?> html плохо

Плохо, когда у Вас там (в php) логика. Например: на странице блок новостей, и когда разметка дошла до этого блока, Вы ставите открывающий php тег, по куче условий строите запрос к БД, достаёте новости, к новостям миниатюры... И через 1-2 страницы кода продолжаете строить разметку, как ни в чём не бывало. ( а посторонний человек уже забыл, где мы и для чего).
Когда PHP используется как шаблонизатор - это не очень удобно, но нормально. Посмотрите на Smarty, один из старейших PHP шаблонизаторов ( до сих пор жив, кстати). Там очень многое выглядит как замена шила на мыло.

Написано 14 апр.
Михаил Ливач @Mausglov

Adamos,

И после всей этой небыстрой эволюции сунуться в реальный мир и обнаружить, что динозавры к этому времени уже вымерли

На то, что я предложил при выборе направления "бэкенд", и в том формате освоения, который я предложил, нужна неделя. Динозавры так быстро не вымирают :)
А к тем, кто делает всё на реактивных фреймворках, приходит заказчик с SEO оптимизатором и заставляют переделывать. И только особо изворотливые могут убедить заказчика потратиться на отдельный сервер ради SSR .
Я не сторонник обучения "давайте бросим в воду, есть шанс, что выплывет". Очень многие не выплывают, и собеседовать их - сплошное разочарование. Предпочитаю закладывать хороший фундамент, и только потом двигаться дальше.

Написано 14 апр.
Adamos @Adamos

Михаил Ливач, просто в процессе эволюции от РНР4 до РНР8 было уж слишком много тупиков...
Фундамент - это прекрасно и необходимо, но может ли им служить это кладбище грабель?
И сейчас бум доткомов сменился волной автоматизаций-интеграций-давайте-наконец-выкинем-Ёксель.
Ни одному сайту из сделанных мной за последние годы никакая SEO, за отсутствием публичной части, просто не требовалась.

Написано 14 апр.
Михаил Ливач @Mausglov

Adamos, я нигде не предлагал начинать с PHP 4 , посмотрите ещё раз.

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

Это Ваш личный опыт. Мой полностью противоположный - магазины и сайты услуг.

Написано 14 апр.
Adamos @Adamos

Михаил Ливач, разумеется, я и не претендую на абсолют. Собственно, я тоже работаю с магазинами, но в виде маркетплейсов ;)
И разве сейчас SEO таких сайтов не упирается в микроразметку вместо верстки? Я правда не в курсе.

Написано 14 апр.
Михаил Ливач @Mausglov
Adamos, классический набор "title, meta description,h1, текст" никуда не делся. Микроразметка тоже важна. Мой опыт взаимодействия с сайтами на реактивных фреймворках таков:
Во-первых, их было мало, по пальцам одной руки можно сосчитать.
Во-вторых, внутри это выглядело так:

минимальная разметка head, одинаковая для всех страниц,

пустой body,

запуск приложения.

Один из проектов потом точно смог в SSR, но страница оказалась забита то ли чудовищным количеством data-атрибутов, то ли монструозным Javascript - не помню подробностей, но показатели PageSpeed упали до плинтуса.
Возможно, сейчас подобные проекты ещё на старте переводятся в режим "только консультации", поэтому я о них ничего и не слышу. А может, им неинтересно SEO.
Написано 15 апр.

Решения вопроса 2

1 комментарий

8 комментариев

EpIvIaK @EpIvIaK Автор вопроса

Спасибо Виктор за ответ!
В общем я в GIT создал новую ветку, удалил всё старое (предварительно скопировав в другое место, т.к. какие-то куски я буду всё же брать оттуда чтоб не совсем с нуля).
Буду пробовать MVC, фреймворк, шаблонизатор, маршрутизатор и вот всё это. Вообще мне уже давно надо было бы делать так.
А я долго рассуждал - мол успеется. Пока в целом буду достигать результата, хоть и криво. А там приложится. Но видимо уже давненько такая философия очень деструктивна.

Позвольте пока одно уточнение. У меня в моей каше кода такая структура.
Главный CSS файл отдельный. Его используют все файлы php-html эти. Но в каждом из этих файлов есть раздел style где или добавляется какая-то специфика для страницы (чтоб тот отдельный не был совсем огромным и запутанным), или (! что важно) я какие-то теги/элементы (которые есть в том главном файле css) модернизирую (так как приоритет тут будет выше стороннего файла и стили переназначаться) и они переназначаются.

И вот теперь думаю как подступиться в этом моменте?

Написано 14 апр.
Виктор Кожухарь @vitiok78

EpIvIaK, Если я верно понял, то у вас каждая страничка - свой отдельный php-файл, в который включена вся разметка страницы? И веб-сервер прямо загружает эти отдельные файлы при переходе на страницы?
Или у вас всё же одна точка входа в приложение - файл "index.php". ?

Написано 14 апр.
EpIvIaK @EpIvIaK Автор вопроса

Виктор Кожухарь, Верно, у меня index.php файл.
И про остальное тоже верно.

Псевдо кодом говоря

CSS файл myStyle
элементы/теги A B C D E описываются какими должны быть.
__
php_1 файл
Подключаем myStyle. Но внутри php_1 в style для B и С меняем характеристики. Плюс для этой страницы добавляем некий элемент G.

И в таком вот духе.
Как это лучше организовать? Был бы благодарен.

И стартовал я на Laravel, пока много нового. Всякие php artisan serve, blade.php.
Пришлось (для локальной работы) ОпенСервер новый поставить, PHP чтоб 8.2 был, Ларавел жаловался на 8.1.

Ещё у меня в старом варианте кода были PHP файлы где намешан был JS + PHP.
Если мы добавляем товар будучи не залогинеными, JS добавлял это в localstorage, если же авторизованы то, если что-то есть в localstorage то в БД заносим, если нет то уже всё равно PHP код в БД добавлять будет, а не в JS-localStorage. Примерно так.

Казалось бы: надо разделить на отдельные JS файлы. Но есть такие ситуации где кусок кода JS - это строк 8-10, тоже что ли отдельные файлы делать?

Написано 16 апр.
Виктор Кожухарь @vitiok78
EpIvIaK,
Я тут подумал, и если вы тренируетесь, то, можно не лезть сразу во фреймворк, а научиться базе.
Советы.

1. Однозначно держать всё в разных файлах. Фронтенд и бэкенд надо чётко разделять. Идеал PHP файла - это <?php в самом начале и больше нигде, даже не закрывать ?> в конце. Кстати, это поможет избежать некоторых багов. Т.е. мы фактически забываем о том, что PHP умеет сам быть шаблонизатором.
Для фронтенда выделяем папочку public, там держим все файлы CSS, JS, картинки и т.д. В этой же папочке держим файл index.php, который является входом в приложение, и в котором будет буквально несколько строчек, которые будут вызывать основной код. А основной код PHP хранить в папке src. Использовать шаблонизатор twig и все шаблоны хранить в папке templates Кстати, пример организации папок и файлов можно посмотреть в том же Laravel или Symfony. Там не дураки это создавали.

2. Научитесь в безопасность. Изучите все основные типы атак, которые используются для взлома бэкенда, и научитесь как с ними бороться. А именно, как предотвращать SQL-иньекции, XSS-инъекции, CSRF атаки. Как правильно организовать сессии, как защищать cookie, как использовать CSRF-токены и т.д. и т.п. Это очень важно, потому что это самая настоящая база, и это вам пригодится вообще всегда и в любом языке.

3. Научитесь создавать правильные API, которые не возвращают всё подряд, и не используют только POST-запросы, а используют GET, POST, PUT, PATCH, DELETE http методы для каждой операции, которые соответсствуют назначению этой операции. Научитесь возвращать правильные HTTP статус-коды ответов и ошибок в зависимости от того, какая ошибка произошла, была ли запись создана либо просто возвращена имеющаяся.

3. Везде прописывайте типы переменных, аргументов функций и возвращаемых функциями значений. Используйте в начале каждого PHP файла директиву declare(strict_types=1); Это очень поможет писать более безопасные программы, избавит вас от целого класса багов.

<?php declare(strict_types=1); function speak(string $name): string { return "Hello {$name}!"; } speak(1); // Это выдаст ошибку "Uncaught TypeError". Нельзя передавать int, когда функция ждет string speak("World"); // Это правильно сработает "Hello World!"

4. Изучите принципы SOLID, но не используйте их, как догму, а просто как подсказку. Принцип DRY также можно держать в голове, но не быть его фанатиком. Принцип KISS - должен вообще стать вашим девизом. Посмотрите в сторону "Clean Architecture" и "Domain Driven Design": они помогут вам организовать структуру кода.

5. ПИШИТЕ ТЕСТЫ!!! Вам не нужно 100% покрытие тестами, но на самые важные функции и классы обязательно нужно писать тесты, и тогда вы не будете бояться вносить изменения в большую кодовую базу, потому что. если вы где-то напишете фигню, тесты упадут и покажут вам, где вы накосячили.

6. Когда более-менее реализуете первые 5 пунктов, можете уже более глубоко изучить фреймворки. И вам тогда станет понятно, что у них там происходит, зачем они всё это ваще наворотили, и почему это хорошо.
Написано 16 апр.
EpIvIaK @EpIvIaK Автор вопроса

Виктор Кожухарь, огрооомное спасибо за такие советы! Пока буду пытаться осмыслить всё это! На это нужно время. Пока лишь вдогонку спрошу - какую лучше версию Laravel использовать? Поставилась LARAVEL v11.3.1 .
Но в Ютубе хорошие уроки (даже курсы) по более старым. И там малость другая структура всего, много отличий.
Сейчас как на рельсы встану, начну практиковать Ваши советы и советы ещё одного тут ответившего.

Написано 17 апр.
Виктор Кожухарь @vitiok78

какую лучше версию Laravel использовать?

Меняются детали, но не меняется общий подход и принципы. Все изменения в новых версиях можно будет легко изучить уже по документации

Написано 17 апр.
EpIvIaK @EpIvIaK Автор вопроса

Виктор Кожухарь, Виктор, изучаю Ларавел. Здравствуйте.
Меня сейчас смущает только одно: один PHP бывалый сказал, что переходит на Go, я так посмотрел картину (вероятно это неверно) - PHP таки устаревает, вероятно через года 2-3 Go будет в фавОре, а PHP всё же станет тонуть в плане востребованности. Но знакомый с большим опытом профессиональным и ему перейти это одно, у меня положение другое.
Я новичок, а есть стереотип (и этот знакомый подтвердил), что в Go войти сложно без большого опыта, в PHP и Ларавел с этим проще. Он добавил что на Ларавел спрос всё ещё есть. Но вот это "всё ещё" смущает. А через год может будет не "всё уже", или чаща весов изменится.
Может Вы скажите на каком из двух вариантов всё же сделать акцент?

Написано 06 мая
Виктор Кожухарь @vitiok78

EpIvIaK,
Я тоже перешёл на Go. Но... Если вы уже начали учить PHP - это вам не повредит. Программист - это не язык программирования. Программист - это адепт секты формальной логики. Если вы научитесь воплощать бизнес-логику заказчиков в код, помогать бизнесу решать его проблемы, то язык тут совершенно не важен. А ещё программист - это существо творческое, что бы там кто ни говорил. А творческому человек необходимо хотя бы немножко получать удовольствие от того, что он делает. Поэтому, можете попробовать немного и то, и другое. И выбирайте то, что вам больше нравится.
Go сейчас на подъёме, и вы не ошибётесь, если выберете его. Но... PHP - далеко не умирающий язык, на нём работает большая половина интернета (WordPress). И вы ещё очень долгое время сможете обеспечить себе хлеб с икоркой...
У Go великолепная стандартная библиотека, просто восхитительные инструменты по отладке, форматированию когда, тестам и т.д. и т.п. Я наслаждаюсь этим языком, хотя многие его считают скучным и многословным.
На PHP написаны два устоявшихся фреймворка (Laravel и Symfony), которые невероятно облегчат вам жизнь. Они умеют всё, что касается веба. На них можно, например, в прямом смысле за полчаса собрать CRUD API с интерактивной документацией.
Если решите идти в PHP, обязательно изучайте WordPress. Потому что установщиков плагинов много, а написать плагин самостоятельно умеют не только лишь все. И такие специалисты ценятся.
При любом выборе самое главное - это английский язык. Без него просто никуда. Потому что на русском языке толковой информации крайне мало.

Написано 06 мая

Пригласить эксперта

Ответы на вопрос 1

2 комментария

EpIvIaK @EpIvIaK Автор вопроса

Понял, спасибо! Приступаю.

Написано 14 апр.
EpIvIaK @EpIvIaK Автор вопроса

Не подскажите?
Изучаю Ларавел. Здравствуйте.
Меня сейчас смущает только одно: один PHP бывалый сказал, что переходит на Go, я так посмотрел картину (вероятно это неверно) - PHP таки устаревает, вероятно через года 2-3 Go будет в фавОре, а PHP всё же станет тонуть в плане востребованности. Но знакомый с большим опытом профессиональным и ему перейти это одно, у меня положение другое.
Я новичок, а есть стереотип (и этот знакомый подтвердил), что в Go войти сложно без большого опыта, в PHP и Ларавел с этим проще. Он добавил что на Ларавел спрос всё ещё есть. Но вот это "всё ещё" смущает. А через год может будет не "всё уже", или чаща весов изменится.
Может Вы скажите на каком из двух вариантов всё же сделать акцент?

Написано 06 мая

Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы

PHP

+1 ещё

Средний
Как при сохранении данных дополнительно отправлять их в файл в контроллере Laravel?
- 1 подписчик
- 15 часов назад
- 64 просмотра
0

ответов
PHP

+1 ещё

Средний
Как писать логи напрямую в Elastic?
- 1 подписчик
- вчера
- 79 просмотров
2

ответа
PHP

Простой
Как сжать в зип архив сайт?
- 1 подписчик
- вчера
- 132 просмотра
4

ответа
PHP

+3 ещё

Простой
Как исправить PHP Warning, если заходить на WordPress через Live Server VSCodium?
- 2 подписчика
- 15 дек.
- 131 просмотр
0

ответов
PHP

Средний
Как исправить ошибку при занесении платежных реквизитов на сайте?
- 1 подписчик
- 14 дек.
- 73 просмотра
1

ответ
PHP

+1 ещё

Простой
Как исправить ошибку «requires ext-zip * -> it is missing from your system. Install or enable PHP's zip extension.»?
- 2 подписчика
- 14 дек.
- 141 просмотр
1

ответ
JavaScript

+2 ещё

Средний
Как сделать чтобы виджетовая форма авторизации от Google не закрывалась?
- 1 подписчик
- 14 дек.
- 68 просмотров
2

ответа
Laravel

+1 ещё

Средний
Пагинация cursor но с соседними страницами?
- 1 подписчик
- 14 дек.
- 67 просмотров
1

ответ
PHP

+2 ещё

Простой
Почему не работает Cron?
- 1 подписчик
- 12 дек.
- 150 просмотров
2

ответа
PHP

+2 ещё

Простой
Как правильно вывести session, чтобы все работало как надо?
- 1 подписчик
- 11 дек.
- 171 просмотр
2

ответа
Показать ещё Загружается…

PHP разработчик

Lachestry • Таганрог

от 170 000 до 200 000 ₽

PHP разработчик Junior+/Middle

amoCRM • Москва

от 130 000 ₽

Backend-разработчик PHP

Wanted. • Москва

До 160 000 ₽

Несложная верстка из Figma bootstrap5 scss npm

18 дек. 2024, в 04:59

1000 руб./в час

Отправка команды на открытие всех окон автомобиля Chery Tiggo 7 Pro

18 дек. 2024, в 03:28

16000 руб./за проект

Установить музыкальный софт

18 дек. 2024, в 01:04

5000 руб./за проект

Михаил Ливач, спасибо большое за критику.

Вы понимаете, что тут захламляете глобальную область видимости? Уверен, что нет. Изучите, что такое модульность и замыкания.

Я правильно понимаю, что тут сводится речь к тому чтоб в отдельном файле js держать это? Т.е об этом речь?

Справочник PHP конечно мне знаком, но с другой стороны безусловно есть вещи ещё непроработанные. yield например и немало чего ещё.
Видимо и правда надо подойти так - прочитать его как книгу, а не пользоваться им по мере необходимости (что бывает часто).

Про echo <<< жаль, что так получилось. Я им пользуюсь не так давно и я понял логику о которой Вы (про смысл был бы если бы в переменную). Я понимаю о чём речь.
Почему же я так делал? Хотелось полумер. Говорили, что смешивать <?php?> html <?php?> html плохо, а тут вроде как в echo<<< я html код как бы интегрирую сразу в PHP пространство.
В общем вышло только хуже.

Да, надо мне с этим всем знакомиться, а то так и останусь на одном месте. Спасибо.
Михаил Ливач,
А уже после этого приступать к Laravel - так как это MVC фреймворк, построенный с ипользованием паттернов проектирования, и который в своём составе содержит шаблонизатор Blade .

И после всей этой небыстрой эволюции сунуться в реальный мир и обнаружить, что динозавры к этому времени уже вымерли и сайты давно делают не на бэкенд-шаблонизаторах, а на реактивных фреймворках, используя Лару только как API.
EpIvIaK, вам стоит попробовать "забыть все, что учили до этого" и нырнуть в Ларавель. Будет непросто, но есть шанс, что вы все-таки, подчиняясь канве этого фреймворка, обойдетесь без заучивания ошибок прошлых поколений и освоитесь с нормальным разделением кода. Потом почитаете правильные книги, подтянете теорию - зачем все это нужно. Уже понюхав пороху, хотя бы и на самом ламерском уровне.
EpIvIaK,

Я правильно понимаю, что тут сводится речь к тому чтоб в отдельном файле js держать
это? Т.е об этом речь?

Нет. Разделение HTML и JS в разные файлы хорошо, но это другое. Название функции validate заставляет предположить, что Вы там проверяете пользовательский ввод. Аргументов функция не принимает ( по сигнатуре). Что Вы будете делать, когда появится ещё одна форма на странице, с совершенно другим содержимым? Или, более наглядно: допустим, у Вас уже есть эта другая форма на другой странице, и тоже есть функция validate() , но с другими проверками. Вы решили эту часть с формой продублировать на первую страницу. Понимаете, что произойдёт?

Короче: если функция нужна только форме, зачем её пихать в глобальную область видимости ( == делать полем объекта window) ? Переделайте в function expression и засуньте в анонимный обработчик для события DOM Ready. Обработчик замкнёт контекст, и будет хорошо.
EpIvIaK,

Говорили, что смешивать <?php?> html <?php?> html плохо

Плохо, когда у Вас там (в php) логика. Например: на странице блок новостей, и когда разметка дошла до этого блока, Вы ставите открывающий php тег, по куче условий строите запрос к БД, достаёте новости, к новостям миниатюры... И через 1-2 страницы кода продолжаете строить разметку, как ни в чём не бывало. ( а посторонний человек уже забыл, где мы и для чего).
Когда PHP используется как шаблонизатор - это не очень удобно, но нормально. Посмотрите на Smarty, один из старейших PHP шаблонизаторов ( до сих пор жив, кстати). Там очень многое выглядит как замена шила на мыло.
Adamos,

И после всей этой небыстрой эволюции сунуться в реальный мир и обнаружить, что динозавры к этому времени уже вымерли

На то, что я предложил при выборе направления "бэкенд", и в том формате освоения, который я предложил, нужна неделя. Динозавры так быстро не вымирают :)
А к тем, кто делает всё на реактивных фреймворках, приходит заказчик с SEO оптимизатором и заставляют переделывать. И только особо изворотливые могут убедить заказчика потратиться на отдельный сервер ради SSR .
Я не сторонник обучения "давайте бросим в воду, есть шанс, что выплывет". Очень многие не выплывают, и собеседовать их - сплошное разочарование. Предпочитаю закладывать хороший фундамент, и только потом двигаться дальше.
Михаил Ливач, просто в процессе эволюции от РНР4 до РНР8 было уж слишком много тупиков...
Фундамент - это прекрасно и необходимо, но может ли им служить это кладбище грабель?
И сейчас бум доткомов сменился волной автоматизаций-интеграций-давайте-наконец-выкинем-Ёксель.
Ни одному сайту из сделанных мной за последние годы никакая SEO, за отсутствием публичной части, просто не требовалась.
Adamos, я нигде не предлагал начинать с PHP 4 , посмотрите ещё раз.

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

Это Ваш личный опыт. Мой полностью противоположный - магазины и сайты услуг.
Михаил Ливач, разумеется, я и не претендую на абсолют. Собственно, я тоже работаю с магазинами, но в виде маркетплейсов ;)
И разве сейчас SEO таких сайтов не упирается в микроразметку вместо верстки? Я правда не в курсе.
Adamos, классический набор "title, meta description,h1, текст" никуда не делся. Микроразметка тоже важна. Мой опыт взаимодействия с сайтами на реактивных фреймворках таков:
Во-первых, их было мало, по пальцам одной руки можно сосчитать.
Во-вторых, внутри это выглядело так:

минимальная разметка head, одинаковая для всех страниц,

пустой body,

запуск приложения.

Один из проектов потом точно смог в SSR, но страница оказалась забита то ли чудовищным количеством data-атрибутов, то ли монструозным Javascript - не помню подробностей, но показатели PageSpeed упали до плинтуса.
Возможно, сейчас подобные проекты ещё на старте переводятся в режим "только консультации", поэтому я о них ничего и не слышу. А может, им неинтересно SEO.

Answer 1 · 2024-04-13 19:43:53

Выводить HTML через echo точно не правильно, изначально PHP полюбили как раз за то, что можно закрыть PHP тег ?> и писать чистый HTML, можно посреди HTML открыть PHP тег <?php и воспользоваться языком, например вывести HTML в цикле (опять же, закрыв тег после начала цикла), или использовать переменную как значение, или выводить HTML по условию.

В Laravel используется шаблонизатор Blade, но если есть ощущение, что Laravel изучать еще рано, можно через composer поставить какой-нибудь самостоятельный шаблонизатор (искать не сложно) и научиться пользоваться им.

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

css стоит писать отдельно и подключать как файл/файлы, для формы будет отдельный шаблон

тут всякие оперативные реакции на действия в браузере требуемые страницей.

js тоже стоит писать отдельно и подключать как файл/файлы

Работа с шаблонами - не самое востребованное знание, скорее очень базовое. Стоит так же изучить:

Архитектурный паттерн MVC (Model, View, Controller), т.к. его все популярные фреймворки реализуют и с ним так или иначе придется работать
Базы данных и SQL. Обязательно нужно уметь проектировать таблицы и индексы, забирать данные из базы и обновлять их
Безопасность, или как правильно писать приложения, что-бы их не взломали SQL инъекциями, XSS атаками и т.д.
Маршрутизацию. Можно попробовать найти какой-нибудь php-router на github и изучить работу с ним, внедрить в проект

Таким образом, приложение будет обрабатывать запрос через некий роутер, посылать его в контроллер (буква C из MVC), контроллер запросит данные в какой-нибудь модели (M), отправит их в шаблон некого шаблонизатора и вернет с его помощью готовый HTML.

После этого можно будет написать такое же приложение на Laravel, где все это уже есть (и даже больше, разумеется), познакомиться с ActiveRecord (объект, который представляет строку в базе данных) и ORM (для построения запросов). Перед началом стоит прочитать всю документацию, изучить возможности.

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

Answer 2 · 2024-04-13 23:23:57

Шаблонизатор - прекрасная и очень нужная штука для PHP.

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

Поэтому, совет перейти на Laravel очень разумен. Это неплохой выбор, фреймворк крайне популярен, в него встроено вообще всё, что вам понадобится для написания практически любого проекта.

Могу дать вам ещё один вариант вместо Laravel. Это Symfony. Да, освоение этого фреймворка будет немного сложнее, чем Laravel, но преимуществом Symfony является то, что он заставляет писать код чище, чем обычно пишут на PHP. Он более строгий, а строгость в программировании всегда к лучшему. Symfony состоит из большого числа компонентов, и собирать проект можно как конструктор. Минимальная его сборка весьма легковесна. Кстати, огромное количество компонентов Symfony используется и в других фреймворках, многие из них можно использовать и без фреймворка.

Как раз таким компонентом, который можно использовать без фреймворка, т.е. так, как вы хотите, является шаблонизатор Twig. Это превосходный шаблонизатор, его легко внедрять.
https://twig.symfony.com/

Но всё же рассмотрите возможность перейти на фреймворк, потому что сейчас в мире PHP почти везде используют именно фреймворки.

Answer 3 · 2024-04-13 16:25:44

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

Переписать грамотнее и с помощью Laravel реально ли и каким лучше образом?

Войдите, чтобы написать ответ

Минуточку внимания

Войдите на сайт