можно на вордпрессе загрузить шаблон и ок

tilda

согласен

Пишешь модель. А миграция создается на основе модели. Я думаю, ларе надо подсосать это

И не стыдится

в смысле

Doctrine

php artisan make:model Product -m

Вообще не понимаю тех кто не использует миграции. Работа в консоли что ли отпугивает

сразу миграция создается под модель

То что ты хочешь называется doctrine

php artisan make:model Product -m

Так это просто пустая создается с таким же именем

php artisan make:model Product -m

Так она пустая

А там типа с полями сразу

можно ещё и контроллер создать)

можно на вордпрессе загрузить шаблон и ок

дайте мьют этому господину )) ?

Да можно такую цепочку файлов на создавать, но они пустые

Да можно такую цепочку файлов на создавать, но они пустые

а какие должны быть?)

@nsweb он как в доктрине хочет, написал ентити и хуяк тебе миграция по ней

Вроде как доктрину с ларой можно подружить

а какие должны быть?)

Лень джангу запускать. В общем когда в ней создал модель, образно name, slug, created_at. makemigrations Уже лежит миграция на основе твоей модели, со слагом неймом и датой, причем по всем правилам и с теми настройками что в модели

Лень джангу запускать. В общем когда в ней создал модель, образно name, slug, created_at. makemigrations Уже лежит миграция на основе твоей модели, со слагом неймом и датой, причем по всем правилам и с теми настройками что в модели

а в моделе описываются все поля? или как?) с джанго нет опыта вообще

вообще не в этом суть) суть в том что миграции - хорошо, без миграций - плохо)

вообще не в этом суть) суть в том что миграции - хорошо, без миграций - плохо)

Это да

Ебнул makemigrations

Жмешь migrate и таблица готова

ммм, не вижу преимуществ... то что в ларе ты пишешь в миграции, в джанго ты пишешь в модели?

Что-то изменил, создалась новая версия

ммм, не вижу преимуществ... то что в ларе ты пишешь в миграции, в джанго ты пишешь в модели?

Так ты ковыряешь модель и миграцию. А так ты ковыряешь только модель и папку миграций можешь вообще ни разу не открывать

Вместо ->change() просто модель отредактировал как надо и создал новую версию миграций

Конечно же не супер быстрее, но проще

Я то уже к ларе давно привык. Но когда переходишь с простого на чуть сложнее, ощущается

ну такое, на вкус и цвет :) со стороны выглядит так что ты запихал ларвел миграцию в модель))

ну такое, на вкус и цвет :) со стороны выглядит так что ты запихал ларвел миграцию в модель))

Наверное)))

+

Стоит разделять такие понятия

в ларавеле как бы не обязательно трогать модель при изменении миграции

да и мне как то спокойнее когда я сам пишу миграции и знаю что и как происходит, а не какая-то "магия" делает за меня эти миграции)

да и мне как то спокойнее когда я сам пишу миграции и знаю что и как происходит, а не какая-то "магия" делает за меня эти миграции)

xDD

что будет если я меняю max-length с 250 на 200 потом запускаю создание миграций, потом меняю обратно на 250 и запускаю создание миграций??? будет 2 миграции?

что будет если я меняю max-length с 250 на 200 потом запускаю создание миграций, потом меняю обратно на 250 и запускаю создание миграций??? будет 2 миграции?

+

что будет если я меняю max-length с 250 на 200 потом запускаю создание миграций, потом меняю обратно на 250 и запускаю создание миграций??? будет 2 миграции?

следует создать новую миграцию для изменений с использованием ->change()

а потом -reset

ой rollback

следует создать новую миграцию для изменений с использованием ->change()

ты про джанго?

аа

я думал про лару

опять контекст не читают)

сори

я думал про лару

Ну ты молодец что написал. мы сравнили зато

А мы являемся IT-сообществом?

ну вот наш ларавель канальчик? :)

Типа на РИТ++ раздавали бесплатно билеты для IT-сообществ :)

@ Берешь такой Lumen, юзаешь, всё ок. @ Разумно отказываешь от фасодов во имя IoC и всяго святого @ Решаешь чтобы ошибки валидатора Json-schema возвращались через Illuminate\Validation\ValidationException @ Сказано - сделано, throw ValidationException::withMessages($validationErrors); @ Скрипт падает от того что фасад не найден @ ибо в ValidationException::withMessages return new static(tap(ValidatorFacade::make

А мы являемся IT-сообществом?

привет! неожидал тебя увидеть тут админом!

@ Берешь такой Lumen, юзаешь, всё ок. @ Разумно отказываешь от фасодов во имя IoC и всяго святого @ Решаешь чтобы ошибки валидатора Json-schema возвращались через Illuminate\Validation\ValidationException @ Сказано - сделано, throw ValidationException::withMessages($validationErrors); @ Скрипт падает от того что фасад не найден @ ибо в ValidationException::withMessages return new static(tap(ValidatorFacade::make

а что такое IoC и зачем от фасодов отказываться?

а что такое IoC и зачем от фасодов отказываться?

гугл в помощь

Спосибо

Спосибо

пожалусто

Дапустим, што пра айос я прочитал, а шо с фасадами не так?

это не толстейший троллинг, рили, что с фасадами не так?

Дапустим, што пра айос я прочитал, а шо с фасадами не так?

а что ты такое прочитал про IoC после чего не задумался что фасады юзать не очень тема ? :)

это не толстейший троллинг, рили, что с фасадами не так?

настолько толстый, что не смешно

прочитал что это di

так что вместо фасада юзать? Например, нужно юзера залогинить Чем мне Auth:: заменить, что бы "красиво"?

Сейчас все про фасады и подобные DI во всех фреймах говорят, что надо отказываться. Ибо в толстеющих проектах это заканчивается адом. В Yii2 это Yii::$app->.... в Ларе фасады, в Symfony контейнеры. Честно говоря, тоже недопонимаю, чем это в итоге плохим таким обернется, если там пол фреймворка любого из перечисленных работает на этом принципе

так что вместо фасада юзать? Например, нужно юзера залогинить Чем мне Auth:: заменить, что бы "красиво"?

Guard ещё есть вроде

ну так, чем заменить в моем примере?

ну так, чем заменить в моем примере?

Написать собственный класс авторизации) Гуард тоже фасадный)

Ну и вмиддлевар его

так по итогу оно же и выйдет

так по итогу оно же и выйдет

Нет. Можно сделать без вызова через DI, все нативными методами php. Но только если так подходить, то и фреймворк не нужен. Думаю, когда весь мир решит отказаться от DI, фреймворки просто перестанут использовать такой подход и будет функционал для этого

Мой совет - не париться и использовать auth::

Так все равно у нас будет один интерфейс и нужно будет как то определять одну из реализаций, т.е. будет где то map с этим делом и такой же самопис будет типа app() для поиска по мапу и синглтон логики?

Так все равно у нас будет один интерфейс и нужно будет как то определять одну из реализаций, т.е. будет где то map с этим делом и такой же самопис будет типа app() для поиска по мапу и синглтон логики?

Без фасадов можно реализовать примерно так. Я точно не помню какой там класс отвечает за объект пользователя. Но суть в том, что ты создаешь класс, в конструктор которого принимаешь объект пользователя, проверяешь пароли и явки, только не через методы Auth, а через bcrypt используя свой уникальный ключик. На выходе при проверке авторизации истина или ложь. Но это довольно геморно. Стоит ли оно того вообще?

Без фасадов легко, просто внедряй зависимости через конструктор либо автовайрингом. Даже если юзать фасады, объясните, зачем они, если можно просто сервис вытащить по имени?

типа класс собрать по имени сервиса , а не по интерфейсу? напиши плиз как будет для Auth

Доброго времени суток. Подскажите пожалуйста по проблеме. при установке eloquent-sluggable:^4.5 для laravel 5.6 вот такая вот ошибка

./composer.json has been updated Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - illuminate/support v5.6.9 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.8 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.7 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.6 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.5 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.4 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.3 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.21 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.20 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.2 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.19 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.17 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.16 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.15 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.14 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.13 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.12 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.11 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.10 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.1 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - illuminate/support v5.6.0 requires php ^7.1.3 -> your PHP version (7.1.0) does not satisfy that requirement. - cviebrock/eloquent-sluggable 4.5.0 requires illuminate/support ~5.6.0 -> satisfiable by illuminate/support[v5.6.0, v5.6.1, v5.6.10, v5.6.11, v5.6.12, v5.6.13, v5.6.14, v5.6.15, v5.6.16, v5.6.17, v5.6.19, v5.6.2, v5.6.20, v5.6.21, v5.6.3, v5.6.4, v5.6.5, v5.6.6, v5.6.7, v5.6.8, v5.6.9]. - Installation request for cviebrock/eloquent-sluggable 4.5 -> satisfiable by cviebrock/eloquent-sluggable[4.5.0]. Installation failed, reverting ./composer.json to its original content.

Ну и?

В чем вопрос?

У тебя 7.1.0

Требует 7.1.3 и выше

спасибо

Требует 7.1.3 и выше

В open server максимум 7.2

Где он его возьмет?

В open server максимум 7.2

7.2 выше чем 7.1.3

В open server максимум 7.2

Ничо, что 7.2 выше 7.1.3?

Ахаха

Я понял

Сук, остановите я сойду

Кто работал с Facebook api?

facebook клиент АХАХАХАХ

Качнул SDK, зарегал апку, делаю запрос и тут такое

To use 'Page Public Content Access', your use of this endpoint must be reviewed and approved by Facebook.

Чого оно еще от меня хочет)?

To use 'Page Public Content Access', your use of this endpoint must be reviewed and approved by Facebook.

тебе же в russian com дали ответ