- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
А это как-то так, будет движком интерпретатором обработчиком %команда% будет?
$response-> по моему более лучший вариант для тебя
Это варианты для разных уровней.
Нужен и оправдан на проекте шаблонизатор. Значит используем шаблонизатор и шаблоны, соответственно html с тегами шаблонизатора. Шаблонизатор сам взаимодействует с билдером.
Если шаблонизатор на проекте избыточен, но нужно управление статическими файлами -используем только билдер.
Если и билдер избыточен можем совсем по простому. Вот варианты обработчика маршурута (специально, для демонстрации обработчики в виде колбеков (конечно по хорошему они в виде классов реализуются, но можно и так:
т.е. имеем четыре зарегистрированных url которые будут отдавать одинаковую страницу, но формировать ее разными способами
--- del
Для пользователя (тот что на уровне шаблона уже) это будет выглядеть так
Конечный синтаксис еще не утвержден, но примерно как то так
Делаешь базовый шаблон вида:
А потом просто наследуешься от него и создаешь кастомные страницы, переопределяя нужные тебе блоки таким образом -
{% extends "base.html" %}
{% block content %}
<link rel="stylesheet" href="{{ url_for('static', path='/css/errors.css') }}">
<div class="container">
<div class="row justify-content-center align-items-center" style="min-height: 70vh;">
<div class="col-md-8 text-center">
<div class="error-content">
<h1 class="display-1 fw-bold text-danger">403</h1>
<h2 class="mb-4">Access Forbidden</h2>
<p class="lead text-muted mb-4">
{{ error_message or "You don't have permission to access this resource." }}
</p>
<div class="mb-4">
<i class="bi bi-shield-exclamation text-danger" style="font-size: 5rem;"></i>
</div>
<div class="alert alert-warning mx-auto" style="max-width: 600px;">
<i class="bi bi-info-circle"></i>
<strong>Need access?</strong> Please contact the administrator or try logging in with appropriate credentials.
</div>
<div class="d-flex justify-content-center gap-3 mt-4">
<a href="{{ url_for('index', lang=language) }}" class="btn btn-primary btn-lg">
<i class="bi bi-house-door"></i> Go to Home
</a>
{% if not is_authenticated %}
<a href="{{ url_for('user_login', lang=language) }}" class="btn btn-success btn-lg">
<i class="bi bi-box-arrow-in-right"></i> Login
</a>
{% endif %}
<button onclick="window.history.back()" class="btn btn-outline-secondary btn-lg">
<i class="bi bi-arrow-left"></i> Go Back
</button>
</div>
</div>
</div>
</div>
</div>
{% endblock %}
Отличная получилсь дискуссия, пока меня упекли(за дело) в баню. Зарекаюсь с экономистами дальше дискутировать)))
Александр, Алексей, MrPi(Сорри, не знаю настоящего имени) - спасибо! Впервые за долгое время - конструктивный разговор, Даже вставки флудеров не испортили.
Дискуссия кстати заставила копнуть разницу между Симфони и Фастапи. Стал понимать ваши трудности. Мне кажется в ФА более логичная структура и правильный рендер аутпута.
Если в симфони профайлер рендерит через тэги, то Фастапи использует шаблоны и готовый контекст.
Это гораздо быстрее.
Ну и роутинг удобнее. Причем можно создавать роуты, которые одновременно будут уметь работать как с REST API, так и с HTML шаблонами.
В чистом виде DRY
Поздравляю, ты переизобрел jinja2. Именно так и работает пайтоновский шаблонизатор.
А они все плюс минус одинаково. Блейд так же примерно. На самом деле я хотел пойти несколько иным путем, но именно тут была реплика, что разработчикам было бы удобнее видеть нечто привычное. я подумал подумал и .... но повторюсь пока это проект. У меня база шаблонизатора уже пережила три варианта, и лишь когда осознал направление куда двигаться вернулся к фреймворку - там не хватало например механизмов интеграции модулей удобной (а шаблонизатор это модуль) :)
Единственное у меня в шаблонах будет только то, что внутри body, остальное декларативно описывается и передается (под капотом) генератору... (посмотрим что из этого выйдет в итоге :) - но хочу попробовать)
Дискуссия кстати заставила копнуть разницу между Симфони и Фастапи.
В плане роутинга мне больше нравится подход как в ларавель. В симфони с его стремлением везде использовать атрибуты (а ранее в phpDoc) мне совсем не заходит. (именно по этому я и сделал больше похожим на лару).
В моем понимании создавая контроллер я не знаю как и зачем он будет использоваться. И на какие маршруты отвечать. Это не ответственность кода контроллера. Это ответственность системы маршрутизации. Если у меня на проекте возникла причина поменять маршруты. (ну условно изменит /api/ на /my_best_api/ - как очень упрощенный частный случай) - то я недолжен лезть в код и проходить все контроллеры.
одни и те же маршруты (а точнее контроллеры) работать с разным типом контента не проблема. Раз уж речь зашла о симфони. тут я покажу сразу в одном примере два маршрута, но суть полагаю понятна - маршрут может остаться и один.
Но! На мой взгляд этот подход не правильный. Контероллер должен быть тонким. что в твоем, что в моем коде есть лишнее условие, которое решаемо на уровне роутинга. Тут, имхо, нарушение и солид (надо дополнить апи, но трогаем класс, который не имеет отношения к апи), SoC - смешиваем логику ответа условно для непосредственного отображения человеку, и обработки программно, пожалуй KISS. Потом rest обычно подразумевает более широкий спектр статусов ответов... ну понято, что ты привел просто пример, но все же нужная ли это фича? :)
В моем понимании создавая контроллер я не знаю как и зачем он будет использоваться. И на какие маршруты отвечать. Это не ответственность кода контроллера. Это ответственность системы маршрутизации.
что в твоем, что в моем коде есть лишнее условие, которое решаемо на уровне роутинга. Тут, имхо, нарушение и солид
Потом rest обычно подразумевает более широкий спектр статусов ответов... ну понято, что ты привел просто пример, но все же нужная ли это фича? :)
Я пока думаю над этим, нашел эту фичу именно читая этот топик. Раньше я всегда отдельно писал АПИ для возврата JSON, отдельно для браузера
У меня будут еще мобильные приложения и наличие такого ответа сильно упрощает код
Нет, ты что то путаешь. Все разделено. Роутинг принимает реквест -делает запрос в менеджер, который в свою очередь может делать запрос в БД, например или еще какая-то логика и отдает назад ответ.
Я про условие "если хочет джсон то .... иначе...."
Я пока думаю над этим, нашел эту фичу именно читая этот топик. Раньше я всегда отдельно писал АПИ для возврата JSON, отдельно для браузера
У меня будут еще мобильные приложения и наличие такого ответа сильно упрощает код
Ну собственно пример выше :), на ларавель тоже можно.
Единственное НО. Обычно для апи и веба разные миддлвары подключают. (настройка на уровне маршрутов и групп маршрутов). В контроллер мы попадаем уже через все эти миддлвары. В АПИ, как правило, не нужны сессии и SCRF токен, но нужен JWT... и там тоже тогда надо проверять с чем работаем? Или речь всегда о стейтлес работе?
Обычно для апи и веба разные миддлвары подключают. (настройка на уровне маршрутов и групп маршрутов). В контроллер мы попадаем уже через все эти миддлвары.
Да, у меня четкое разделение и все запросы в апи идут через JWT токен. По факту, существующий фронт - временное решение чтобы не заморачиваться, он все равно передет на Реакт. Так что или писать отдельную апи или проверять запрос и в зависимости от него отдавать результат.