• Есть ли в laravel обычная модель, не Eloquent ORM?

    SerafimArts
    @SerafimArts
    Senior Notepad Reader
    ikudryash:
    1) Модель (везде) - это просто прикладной уровень доменного объекта (т.е. некоторый объект, отображающий предметную область). Она ни от чего не зависит и ничего не требует (в т.ч. наследования).
    2) AR-модели (ну или любые другие анемичные модели) никогда и не при каких условиях не должны содержать валидацию бизнес-процессов. Эта зона ответсвенности DbC инвариантов. Если это не нравится - обычной практикой считается DTO. В случае Laravel - вам всё упростили и запили на блюдечке FormRequest'ы, которые автоматом валидируются при резолве из контейнера (т.е. при инжектах).
    3) Валидация бизнес-логики должна всегда находиться на уровень выше, т.к. правила создания сущностей привязаны к непосредственной области действия (в том числе прав пользователя и прочего, т.е. зависит от задачи) и может быть разной в разных местах.
    4) Для использования внешних сервисов в Laravel есть контейнер, который реализует автовайринг и двойную диспатчеризацию, в отличие от Yii, где подобного нет и фрейм нашпигован скрытыми зависимостями.
    Ответ написан
    1 комментарий
  • Какие PHP стили записи существуют?

    stanislav-belichenko
    @stanislav-belichenko
    Backend PHP Developer
    Я пишу на Laravel мне не нравится что постоянно необходимо создавать 2 функции 1ну для отображения вьюхи 2 для самой логики


    Если коротко, то все ваши проблемы из-за того, что вы не совсем верно неверно поняли модель MVC. Если вы бы иначе построили структуру своего приложения, то вас не смущали бы "две функции".

    Модель MVC, которой следуют практически все фреймворки, за которые вы сможете взяться, предполагает именно такую структуру - на каждое действие должен быть свой контроллер или его конкретный метод, при этом контроллер объединяет методы для какой-то одной логической единицы.

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

    То, что вы в данный момент используете - это совсем не right way. И точно так же не right way делать в одном контроллере две "функции" (на самом деле - два метода класса вашего контроллера), одна из которых будет что-то вроде showRegister(), а другая - createRegister(). Правильный в вашем конкретном примере вариант - это разбить вашу логику на две (три) логические единицы (два/три контроллера или группы контроллеров), одна - показ страниц бекенда / фронтенда, а другая - обработка задач авторизации. В итоге у вас должно будет получиться что-то вроде:

    app
    ...
    ├── Http
    │   ├── Controllers
    │   │   ├── Auth // 1. тут мы обрабатываем роуты, ответственные за авторизацию
    │   │   │   ├── ForgotPasswordController.php
    │   │   │   ├── LoginController.php
    │   │   │   ├── RegisterController.php
    │   │   │   └── ResetPasswordController.php
    │   │   ├── Backend // 2. тут мы показываем бекенд
    │   │   ├── Frontend // 3. тут мы показываем фронтенд
    │   │   │   ...
    │   │   ├── Controller.php
    │   │       ...
    ...


    В пунктах 2 и 3 вы в выводимых ими вьюхах используете роуты, которые про авторизацию, и у вас в итоге будет отдельная группа роутов вроде /auth/* и отдельные группы вроде /* (главная) и /admin/*.

    Согласитесь, теперь все выглядит логично и понятно. И "стили записи" тут совершенно ни при чем.
    Ответ написан
    4 комментария
  • Не видит класс HTML! Laravel?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега Laravel
    3 комментария
  • Правильно ли организована БД и результативен ли такой запрос в Laravel?

    Sanasol
    @Sanasol Куратор тега Laravel
    нельзя просто так взять и загуглить ошибку
    В чем вопрос?
    У вас всего одна категория, испортить что-то трудно, в запросе ничего сложного.

    А за zakaz_tovar, dostavka и т.д. хочется ударить, честно. Неужели трудно открыть гугл транслейт если слово не знаете.
    Тем более orders и products уже есть, order(s)_products.
    Ответ написан
    7 комментариев
  • Почему Laravel выдает ошибку при присвоении?

    Sanasol
    @Sanasol Куратор тега Laravel
    нельзя просто так взять и загуглить ошибку
    решил попробовать 5.3

    уже 5,4 давно

    Ну попробуйте свои касты прописать
    https://laravel.com/docs/5.4/eloquent-mutators#att...

    Где-то что-то не так сделали, раз он за дату принимает поле
    Ответ написан
    2 комментария
  • Каким образом лучше всего интегрировать ReactJS с Laravel?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    Приложения написанные на react/angular/и т.д. ожидают на бэкэнде API.

    1. Создаете API
    2. Внутри ваших компонентов "общаетесь" с вашим API
    Ответ написан
    Комментировать
  • Почему не известна переменная?

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Скорее всего по тому, что Вы используете там т.н. колбэк-функцию (или по русски - функцию-замыкание), а область её видимости обычно строго ограничена.

    Думаю, ситуацию исправило бы примерно следующее:
    Mail::send('email_verify', $data, function($message) use ($user) { ...


    Тут немного подробностей.
    Ответ написан
    Комментировать
  • Знания Junior php разработчика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что должен знать идеальный джуниор (мое личное мнение):

    - Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
    - GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
    - Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
    - PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
    - Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
    - Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
    - Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
    - Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
    - Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
    - Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
    - Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
    - Уметь дебажить. xdebug, blackfire и тд.

    В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

    p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

    Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.
    Ответ написан
    12 комментариев
  • Как научиться создавать свои функции в PHP?

    ronik55
    @ronik55
    Simply good guy, who can press any key ;)
    Лентяй детектед
    Ответ написан
    Комментировать
  • Как научиться создавать свои функции в PHP?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Реально ли вообще с нуля самому не смотря не документацию или чужой код создать Движок?


    Нет. Хватит лениться.
    Ответ написан
    Комментировать
  • Как защитить изображения от PrintScreen?

    Serj-One
    @Serj-One
    i'm sexy and i know it
    Всё содержимое страницы априори доступно пользователю. Кому нужно, вытащат из кода.
    Защита от PrintScreen - турникет в поле, причём не просто не выполняющий свою функцию, но ещё и постоянно бьющий по бубенцам его поставившего.
    Ответ написан
    3 комментария
  • Что бы учить Laravel, обязательно знать php полностью или основы подойдут?

    @DP-Studio
    20 лет веб-разработки
    А что такое "знать php полностью?" Помнить наизусть всю реализацию стандартных функций? Или уметь написать "Hello World"? Что-бы начать работать с инструментом, его можно вообще не знать. Для начала работы с современными php фреймворками рекомендуется:
    1. Уметь вывести в браузер Hello World средствами php
    2. Знать что такое ООП в общих чертах
    3. Прочитать статейку другую по парадигмам программирования, в частности об MVC
    4. Обложиться доками, Наискось просмотреть php.net, наискось просмотреть доки Laravel, Наичкось просмотреть Laravel API
    5. Сесть и писать первый проект.
    6. Никому никогда этот проект не показывать и выбросить в корзину когда будет готов.
    7. На основе выброшенного проекта и полученного опыта начать новый проект.
    8. Пункты 5-7 повторить от 5 до 10 раз.
    9. Можно начинать работать с фреймворком...
    Ответ написан
    Комментировать
  • Почему не работает laravel?

    Denormalization
    @Denormalization
    >No supported encrypter found. The cipher and / or key length are invalid
    Ключ скорее всего не указан в config/app.php (key/cipher)

    Сгенерить можно
    php artisan key:generate
    Ответ написан
    9 комментариев
  • Что такое static в ООП php?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Для этого вам надо понимать в чем разница между классами и объектами. Вот есть методы и свойства объектов а есть методы и свойства классов. Последние как раз статические свойства и методы. Отсюда и все особенности их работы и возможные варианты использования. Класс у нас в системе может быть только один, а экземпляров этого класса (объектов) много.

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

    $foo = Singleton::instance();
    $bar = AbstractFactory::create('bar');
    $buz = Buz::fromArray([
        'many' => 'arguments', 'Buz' => 'has', 'private' => 'constructor'
    ]);


    В PHP статику еще любят применять как замену обычным функциям в силу того, что для классов автозагрузка у нас есть, а для функций нету. Не сказать что это сильно хорошо, я бы даже сказал что это плохо. Учитывая что сейчас есть composer а благодаря opcache оверхэда от подключения для каждого запроса файла особо и нет. В целом лучше стараться избегать использования статики или во всяком случае делать в статических методах хоть сколько нибудь сложные вещи. И лучше всегда ограничиваться только случаями для порождения объектов, тут статика выглядит логично.

    Если рассматривать с точки зрения пораждающиз статических методов, нам так же надо знать кого создавать. И тут появляются два ключевых слова - self и static. Причем self равносильно написанию имени класса в котором наш статический метод находится и просто позволяет уменьшить дублирование. static же намного интереснее, так как оно указывает непосдерственно на тот класс, из под которого был совершен вызов. Скажем если у вас есть наследование вы можете запихнуть порождающий метод в базовый класс, и тогда узнать кого создавать в принципе не проблема.

    class Foo {
        public static function createWithSelf() {
             // равносильно new Foo();
             return new self();
        }
        public static function createWithStatic() {
             // а тут мы пока не знаем кто такой этот static
             $foo = new static();
        }
    }
    
    class Bar extends Foo {}
    
    $foo = Bar::createWithSelf(); // тут будет экземпляр Foo
    $bar = Bar::createWithStatic(); // тут будет экземпляр Bar
    Ответ написан
    1 комментарий