Дмитрий Энтелис: До фреймворков надо дорасти, для этого некоторое время писать код на голом пхп и страдать :) А так согласен, книжку сжечь, ибо ужас-ужас.
Александр: Тогда надо проверять неравенство выдачи strpos и FALSE, т.к. подстрока может встретиться на 0-й позиции, и, хотя, это валидный результат, он будет расценен как FALSE. Другими словами тогда уж надо делать так {if strpos($smarty.server.REQUEST_URI, "текст_который_должен_быть_в_урл")!==FALSE}
Открываешь налоговый кодекс, смотришь срок давности по налоговым преступлениям. Смотришь суммы по крупным и особо крупным размерам по уклонению. Смотришь административные, уголовные меры и штрафы, которые за это полагаются. Осознаешь, что в век облаков абсолютно все транзакции по абсолютно всем счетам абсолютно всех физиков и юриков уже лет пять как хранятся и будут храниться вечно. Осознаешь что технологии бигдата развиваются семимильными шагами, и уже достаточно скоро налоговые органы смогут в этом море транзакций в реальном времени отслеживать все что угодно. Осознаешь, что 6% налог, плюс соцплатежи, которые, причем, этими 6% налогами покрываются, если оборот позволяет, это совсем не дорого за то, чтобы спать спокойно. Осознаешь что всякие пайонеры и прочие мутные схемы будут стоить никак не меньше тех же 6%...
И, я думаю, выводы уже делаешь в годном направлении.
У меня хром жрет гораздо больше, правда я постоянно держу открытыми десятки вкладок. Когда моих 12 гб оперативки перестает хватать, я просто перезапускаю хром.
Ясен прекрасен, что не всякий сайт нужно делать в виде SPA, однако нечто динамичное однозначно нужно.
Сухроб Хусамов: Мне кажется меню строить следует средствами фронтенда. Для меня бэкенд давно стал не более чем прокси между фронтендом и базой данных, ну и еще несколько функций, но не более того. Да, конечно, предварительный рендеринг необходим, но, опять же, это делается средствами фронтенда, просто код исполняется на бэкенде.
Вообще я считаю в корне неверным тянуть привычки 5-7-летней давности в современный веб-дев - он другой и требует других подходов.
Алексей Чалый: Ну раз так, я бы рекомендовал для начала для самого себя внести ясность в терминологии. Разобраться, что такое аутентификация, авторизация, роли. Копать можно начинать в сторону RBAC.
Я долго писал на JS/jQuery, и когда дело дошло до более-менее сложных SPA, выяснилась неприятная вещь - сопровождать, и, упаси Бог, дораабатывать то, что было написано несколько месяцев назад НУ ОЧЕНЬ НЕПРОСТО. Хаотичные связи, полная анархия по части модификации DOM кем угодно, где угодно, когда угодно... В общем ад и хаос в одном флаконе.
Я, как человек ленивый, предпочитаю жесткий контроль происходящего, другими словами, порядок.
Так вот, ангуляр мало чем отличается от jQuery в это плане - такой же ад и хаос.
В конечном счете я выбрал для себя React.JS+Redux+Router+...
Логика тут простая - меняем стейт приложения в одном единственном месте централизованно, а все изменения оперативно отражаются в интерфейсе АВТОМАТИЧЕСКИ. Т.е. процессы идут односторонне, прозрачно, понятно и управлять всем этим ПРОСТО.
Прежде чем вникать в паттерны, я считаю, необходимо накопить некоторый боевой опыт, чтобы в этих паттернах возникла реальная необходимость. Паттерны хороши, когда уже понимаешь для чего они нужны не в теории, а на практике, иначе это просто засорение головы...
Принцип необходимости и достаточности никто не отменял.
Мир WEB стремительно меняется, все больше "магии" уходит с серверов и облаков на клиента, если нет особого бэкграунда, я бы некомендовал сместить акценты с PHP на JavaScript...
В WEB'е клиенту никогда не было никакого доверия. Нет абсолютно никаких гарантий что там на том конце и по существу наверняка убедиться в этом тоже нет 100% способов. Поэтому однозначно на стороне сервера дожно решаться, и желательно не доходя ни то что до скрипта пхп, а лучше и до апача, т.е. на уровне nginx...
Чем быстрее отработает скрипт на сервере и отдаст в клиент контент - тем лучше. Скрипт - который ничего не делает 3 секунды - тем не менее потребляет массу ресурсов, начиная от сетевого соединения и заканчивая памятью, выделенной интерпретатору... Ну и так далее...
Если никак не проверять что пришло в запросе с клиента, то залётный хакер сможет зачотно порезвиться, пытаясь угадать названия классов-методов, не имеющих отношения к позволенному функционалу. Для неавторизованных пользователей я бы вообще обработку запросов жестко ограничил.
