Задать вопрос
  • В чем суть роутера на php?

    onqu
    @onqu
    weasy
    1. Здесь пугают всякими контроллерами, ларавелями. Давайте жить проще. Для начала дадим определение модному слову роутер. Это маршрутизатор. Что делает маршрутизатор? Правильно. Обрабатывает маршруты, являясь связующим звеном. Маршрутом для web сайта принято считать метод запроса [GET, POST, PUT и другие] и компоненты URI.

    например: https://ru.wikipedia.org/wiki/URI?foo=bar#title
    [схема: https] :// [источник: ru.wikipedia.org] [путь: /wiki/URI] [запрос: ?foo=bar] [фрагмент: #title]


    Но для определения маршрута может браться любая другая информация передаваемая серверу, определение выше это лишь наиболее употребляемые параметры.

    Сама работа, как правило проста: от клиента приходит запрос, маршрутизатор перебирает все заданные ему пути до первого совпадения. При совпадении вызывается определенная вами функция, которая возвращает ответ клиенту.

    2. Он необходим, если в приложении одна точка входа, когда любой запрос приходит на один файл.

    3. Простой пример
    // файл index.php
    
    // Маршруты
    // [маршрут => функция которая будет вызвана]
    $routes = [
        // срабатывает при вызове корня или /index.php
        '/' => 'hello',
        // срабатывает при вызове /about или /index.php/about
        '/about' => 'about',
        // динамические страницы
        '/page' => 'page'
    ];
    
    // возвращает путь запроса
    // вырезает index.php из пути
    function getRequestPath() {
        $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
    
        return '/' . ltrim(str_replace('index.php', '', $path), '/');
    }
    
    // наш роутер, в который передаются маршруты и запрашиваемый путь
    // возвращает функцию если маршшрут совпал с путем
    // иначе возвращает функцию notFound
    function getMethod(array $routes, $path) {
        // перебор всех маршрутов
        foreach ($routes as $route => $method) {
            // если маршрут сопадает с путем, возвращаем функцию
            if ($path === $route) {
                return $method;
            }
        }
    
        return 'notFound';
    }
    
    // функция для корня
    function hello() {
        return 'Hello, world!';
    }
    
    // функция для страницы "/about"
    function about() {
        return 'About us.';
    }
    
    // чуть более сложный пример
    // функция отобразит страницу только если
    // в запросе приходит id и этот id равен
    // 33 или 54
    // [/page?id=33]
    function page() {
    
        $pages = [
            33 => 'Сага о хомячках',
            54 => 'Мыши в тумане'
        ];
    
        if (isset($_GET['id']) && isset($pages[$_GET['id']])) {
            return $pages[$_GET['id']];
        }
    
        return notFound();
    }
    
    // метод, который отдает заголовок и содержание для маршрутов,
    // которые не существуют
    function notFound() {
        header("HTTP/1.0 404 Not Found");
    
        return 'Нет такой страницы';
    }
    
    
    // Роутер
    // получаем путь запроса
    $path = getRequestPath();
    // получаем функцию обработчик
    $method = getMethod($routes, $path);
    // отдаем данные клиенту
    echo $method();


    На практике используют более сложные маршрутизаторы, у которых гораздо большие возможности.

    4. Обойтись без него можно. Если каждая страница в вашем приложении будет являться отдельным файлом, который отвечает за отдачу информации.
    index.php
    about.php
    contact.php
    ...


    Это олдскульная структура, в новых проектах почти не применяется.
    Ответ написан
    13 комментариев
  • Как разобраться в философии symfony2?

    @shoomyst
    dumb
    Symfony это конструктор, который поставляется в собранном виде. Но ничто не мешает вам его разобрать и собрать по-своему. Многие критикуют фреймворк за это качество: нет ощущения целостности как у Yii или Laravel. Похожее говорили в свое время про Zend1: монстр, куча несвязанных компонент, лучше я буду кодить в своем уютном CodeIgniter-e.

    Symfony Framework - это (грубо) HttpKernel + DependencyInjection Container (DIC) + EventDispatcher.

    Главное задачей HttpKernel является конвертирование Request в Response. Для этого он загружает и инициализируется бандлы, создает контейнер (DIC), пытается по Request определить контроллер, выполнить его и убедиться, что результат выполенения контроллера является объектом Response, если нет, то пытается преобразовать результат в Response.

    DIC занимается созданием и хранением сервисов, если совсем грубо, то это такой навороченный Registry.

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

    Бандлы лучше всего сравнить с плагинами. Есть ядро, которое было описано выше, а бандлы это плагины для него, добавляющие некий функционал (FrameworkBundle, TwigBundle, MonologBundle). FrameworkBundle это основной плагин, который добавляет основной функционал: формы, валидация, сессии, translations. При желании его тоже можно заменить как и любой другой. Другой задачей бандлов является интеграция различных библиотек в ваш проект: twig, monolog, swiftmailer (поставляются с симфони), sphinx, elastic и т.д. Ну и логика приложения так же может быть размещена в бандлах.

    Чтобы Symfony узнал про ваш бандл, его необходимо зарегистрировать в AppKernel.

    У каждого бандла есть своя конфигурация, с помощью которой он может интегрироваться в Symfony:
    1. Регистрация своих сервисов в DIC. Далее вы можете использовать их, например, в контроллере: $container->get('sphinx.search')->query(...)
    2. Бандл может повесить свои сервисы на какие-то события. Например, на событие KernelEvents::CONTROLLER, тогда ваш бандл получит управление при подборе контроллера и вы сможете обойти штатный механизм подбора и вернуть свой, который и будет выполнен.
    3. Использование тегов. Например, вы создали класс HelloWorldViewHelper и хотите его подключить в Templating. В конфигурации указываете для него тег "templating.helper" и он будет подхвачен Symfony и встроен в шаблонизатор.
    Ответ написан
    6 комментариев
  • Как разобраться в философии symfony2?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

    Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

    Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

    | - app
    | - var
    | - src
      | - Controller
      | - Entity
      | - Bundle/
        | - MyAuthBundle/
    | - web


    ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

    Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.
    <div id="sidebar">
        {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
            'max': 3
        })) }}
    </div>


    Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.
    Ответ написан
    8 комментариев
  • Считается ли фриланс за опыт работы?

    @proffard
    Конечно указывайте!

    Только пишите не "фрилансил с 2012-2014", а разбейте по проектам, которые делали.
    Таким образом ваши проекты превратятся в привычные места работы с описанием обязанностей и достижений.

    Говорю не просто так, мы пару месяцев назад взяли в команду такого вот фрилансера, у которого было именно такое резюме, которое нас впечатлило. Также в том, что кандидат был фрилансером есть 1 огромный плюс: это реальный показатель самостоятельности.
    Ответ написан
    1 комментарий
  • Насколько хорошо PHP работает в облаках?

    bboytiwst
    @bboytiwst
    Насколько хорошо PHP работает в облаках?

    Максимально хорошо
    Ответ написан
    Комментировать
  • Какие подводные камни Google App Engine?

    Вот тут особенности запуска приложения на PHP: https://developers.google.com/appengine/docs/php/
    А вот тут работа с файлами: https://developers.google.com/appengine/docs/php/g...
    Если используете вместе с MySQL то это будет обычное PHP приложение которое можно перенести на обычный хостинг после небольших доработок.
    А так как для PHP по сравнению с Python сильно ограничен выбор сервисов GAE которые можно использовать в приложении, то проблема с переносом становится еще меньше.
    Т.е. по сути делая приложение на PHP вы просто используете автоматическое масштабирование виртуальных серверов и балансировщик нагрузки.
    Подводные камни могут попадаться при работе с Datastore (которого в PHP нет) и другими сервисами GAE типа Search.
    Ответ написан
    Комментировать
  • Какие подводные камни Google App Engine?

    AmdY
    @AmdY
    PHP и прочие вебштучки
    Зачем вам эта какашка, которая годами не могла ввести поддержку php, когда есть прекрасный https://forge.laravel.com/
    Ответ написан
    4 комментария
  • Стоит ли использовать малоизвестные технологии при разработке, чтобы "привязать" к себе заказчика?

    iiil
    @iiil
    Инженер и вэб-дизайнер, рисую.
    Заказчика лучше удерживать другими способами, например, качеством работы.
    По мне так большинство и так достаточно ленивы, чтобы менять исполнителей. Это же каждый раз риск, трата времени.
    Кроме того, малоизвестные технологии скорее всего и развиваются медленно, имеют риск умереть. Представляете, как будете оправдываться перед заказчиком, почему не можете сделать ту или иную фишку, которая есть уже у всех его конкурентов. Что Вы ему скажете?
    Ответ написан
    Комментировать
  • Копирование большого файла с Mac OS X на Windows?

    shadowalone
    @shadowalone
    не разбивайте архив встроенными средствами GUI на маке, используйте коммандную строку, все собереться потом в винде на «ура». проверено.
    Ответ написан
    3 комментария