А ты в курсе, что речь про фреймворк, а не твой собственный проект? Никакого "потом" у мейнтейнеров фреймворков нет. Ты должен здесь и сейчас сделать нормально. Это тебе не пет проект, который потом можно отрефакторить. Нельзя. У тебя есть BC и ответственность перед пользователями.

а основная идея Тейлора, насколько я её вижу, это всего лишь "достичь нужного результата с минимально возможным пользовательским кодом".
вкатившись в ларавель после Zend Framework'а, где постоянно приходилось делать "восход и закат солнца вручную", я его оч хорошо понимаю =)
моя единственная претензия к ларке — это слишком толстый бутстрап.
в остальном — вполне себе ок, потому что позволяет решать любого уровня задачи, не стесняя тебя практически ни в чём.

именно! фреймворк должен предоставлять кучку "магии", т.е., грубо говоря, одной строкой выполнить базовую стандартную функцию, но и в то же время должен предоставить возможность достаточно просто tweak'ать любое место в потрохах, чтобы юзер (который программер) мог адаптировать фукнционал под свои нужды, если вдруг ему "захотелось странного".

> почему-то это сразу приводит к п. б) — т.е. перегруженному всякой лишней фигнёй коду

Почему-то перегруженный всякой фигней код как раз у ларавеля. Зачем вообще такая фича как "генерация пдф" во фреймворке? Есть этому разумное объяснение? Всем проектам нужна генерация пдф? Мне, например, такая фича не нужна. Тебе нужна? Полагаю, нет. Тогда зачем это тащить во фреймворк? Генерация отчета – это функционал сбоку, где каждый разработчик волен выбрать себе любую либу и прикрутить. С теми усилиями, с которыми фичи делает Тейлор, там не то что пользы не будет, но и вреда добавится. Наверняка под конец вытащит это все в еще один трейт HasPdf/CanBeGeneratedAsPdf.

а ВС здесь, кстати, вполне норм: при переходе с пятёры на семёру, пришлось только Translator потрогать, и вроде как всё =)

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

> я против любого вида экстремизма. если всё делать "по книжкам", то почему-то это сразу приводит к п. б) — т.е. перегруженному всякой лишней фигнёй коду. считаю это юношеским максимализмом, желанием "сразу сделать хорошо", хотя этого здесь и сейчас(!) не требуется.

Смотря, какие книги читать. Мне, к счастью, ни разу не попадалась книга, где говорили бы, что надо перегружать код абстракциями, нужно делать больше фичей, чем нужно. Почему-то я читал про DRY, KISS, YAGNI и SOLID, где код выглядел совсем иначе. Он простой, он делает только то, что очевидно из названия. Его легко конфигурировать. У него мало входящих зависимостей. Более того, он позволяет тебе выбрать любой драйвер, если речь про бд, генерацию, сессии, поставив всего лишь нужный пакет. Так что хз какие книги читал ты.

Да, возможно. Читал ночью, только проснувшись, показалось, что это его новая киллер-фича.

Толстый бутстрап, кстати, скорее всего из-за того, что контейнер не компилится , хотя может какие-то свои механизмы есть.

Не компилится и никаких механизмов нет. Тот кэш провайдеров, что делает ларавел, как коту сосиска. Вообще никакого перфоманса не добавляет.

да все те же книжки я тоже читал, а с некоторыми их авторами и в интернетах общался =)
всё хорошо и красиво на бумаге, но потом приходит злой дядька опыт и намекает, что все эти Аффтары хорошо если за свою жизнь пару проектов выкатили в продакшен (обычно и того нет) и поддерживали потом несколько лет =)

и выходит, что вся та мнимая чистота и простота кода получается лишь за счёт того, что ты просто спрятал "некрасивое" за кучей абстракций и паттернов. оно никуда не делось, оно там есть, просто ты сам не хочешь его видеть.
но код уже сложный — чтобы понять, что делает $this->сделатьКрасиво(), надо погружаться в глубины абстракций, десятка файлов, лишних экранов boilerplate-кода.

и, давай признаем, что не меняем мы СУБД на проекте каждую неделю!
что если делаешь на Постгресе всё, то у тебя все SELECT-ы оптимизированы на него, и на мускуле оно уже по определению не пойдёт.
что проект скорее перепишется с нуля, чем будет мигрировать куда-то там "вмонгубля!" =)

все эти абстракции и паттерны нужны когда функционал уже сложный.
но если у тебя одна только стратегия, то и паттерн Стратегии ещё рано вводить. лучше сделать всё прямолинейно и просто, а вот когда появится вторая стратегия, ты уже знаешь, в какую сторону ты быстро всё отрефакторишь, потому что читал правильные книжки =)

Подскажите, правильно ли я делаю.

Поступил запрос на создание Soap сервиса для клиента. Клиент дал xsd структуру для запроса и ответа на каждый метод который запросил.
Я создал руками wsdl, указав в блоке types xsd структуры клиента как есть. Ну кроме первой строки с xml версией и прочей метой.

Но при попытке запустить тест на вызов метода SoapServer'а из SoapClient'а выпадает SoapFault
Return type is not XML.
Сервер поднят локально через команду artisan serve.
SoapUI при попытке сделать вызов показывает html с 419 ошибкой. URL сервиса закрыта auth middleweare.

нужно смотреть, что именно получает SoapClient.
ошибка "Return type is not XML." скорее всего означает, что у тебя пара warning'ов вылезла перед ХМЛ-контентом

я уже пытался найти эту проблему, но нечего не вышло... Может ли это быть связано с выводом PHPUnit или работой трейта RefreshDatabase? как вообще отловить вывод до точки в коде / тестах?

opcache нужно включать локально или на проде?

не знаю, но я бы постарался сначала сделать так, чтобы SoapUI отрабатывал штатно: например, Cookie подсунуть ему с уже готовой авторизацией, или, если есть возможность, временно отключить авторизацию вообще

а ты как думаешь?

На деве

локально не надо, на проде наверное надо

угу