Есть же ещё компоненты. Не спа говно и не олдскул. И тем более не шаблонизация жс

что то не понял

если у вас не SPA с совсем отдельным фронтэндом, то яваскриптовая часть полюбому - говнокод :)

если у вас не SPA с совсем отдельным фронтэндом, то яваскриптовая часть полюбому - говнокод :)

Спорное и имхо неверное утверждение

Спорное и имхо неверное утверждение

ну речь скорее не об spa а о фреймворках

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

я сам сейчас проект с jquery делаю, у меня большой файлик в котором все перемешано, какой то четкий функционал просто выношу в отдельный файл, но что то большее мудрить просто нет смысла

если у вас не SPA с совсем отдельным фронтэндом, то яваскриптовая часть полюбому - говнокод :)

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

Макс все правильно сказал

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

ну id через атрибуты - это ессно. но то, что надо json_encode... какаято странность, не?

ну id через атрибуты - это ессно. но то, что надо json_encode... какаято странность, не?

да есть немного

короче говнокод наше все

кароч все друг друга поняли.

смысла продолжать нет :)

давайте лучше обсудим как правильно делать сервисы )

кстати никто не знает в чем фишка контрактов в ларавеле?

кстати никто не знает в чем фишка контрактов в ларавеле?

в идиотском неймспейсе Contracts которым делает весьма неудобным нормальное использование их, через DI..

ну не то чтобы неудобное, но всегда можно случайно use сделать класса, а не интерфейса.

в идиотском неймспейсе Contracts которым делает весьма неудобным нормальное использование их, через DI..

вот я не понимаю нахер так сделали

или ты про какие контракты?

да, Тэйлор же у нас бог ООП :))

я стати как раз об этом сейчас пишу :)

есть два тупых варианта выделить интерфейс

Чем больше я узнаю ларавель тем больше мне хочется пересесть на симфони )

я стати как раз об этом сейчас пишу :)

где?

неймспейс Contracts или FooInterface, BarInterface

Чем больше я узнаю ларавель тем больше мне хочется пересесть на симфони )

ты еще в код не смотрел там :)) там много чего прикольного

ну не то чтобы неудобное, но всегда можно случайно use сделать класса, а не интерфейса.

В смысле? Это как?

неймспейс Contracts или FooInterface, BarInterface

почему во всех нормальных проектах интерфейсы хранят рядом с пакетом от которых они зависят? Это же гораздо лучше чем вынести все в отдельную папку

В смысле? Это как?

__construct(Repository $config)

что меня больше удивляет что под контракты выделена отдельная глава в доке )

а потом надо сделать use

что меня больше удивляет что под контракты выделена отдельная глава в доке )

покажи :)

как будто это какое то архитектурное решение

https://laravel.com/docs/5.6/contracts

__construct(Repository $config)

А ты что хочешь что бы у него постфикс интерфейс был?

Ты же сам орал что это не нужно

А ты что хочешь что бы у него постфикс интерфейс был?

чтобы был interface Config and interface Cache.

а не интерфейсы Cache\Repository & Config\Repository

тот кто это придумал - баран

как будто это какое то архитектурное решение

Не подключая пакет реализуешь контракт и ты подменил своим

и я почти уверен что это Тейлор :)))

а не интерфейсы Cache\Repository & Config\Repository

Пфф

Не подключая пакет реализуешь контракт и ты подменил своим

Так зачем это называть контрактами? Это обычные интерфейсы.. Их выносят вларавеле в отдельную папку.. Где то просто есть у тебя в пакете папка Respository и там лежит RepositoryInterface..

По структуре все логичнее получается

Так зачем это называть контрактами? Это обычные интерфейсы.. Их выносят вларавеле в отдельную папку.. Где то просто есть у тебя в пакете папка Respository и там лежит RepositoryInterface..

контракт класса это синоним слова интерфейс

Так зачем это называть контрактами? Это обычные интерфейсы.. Их выносят вларавеле в отдельную папку.. Где то просто есть у тебя в пакете папка Respository и там лежит RepositoryInterface..

а где классы, его реализующие?

контракт класса это синоним слова интерфейс

Я понимаю, но незачем их выносить в отдельный неймспейс

контракт класса это синоним слова интерфейс

также как и фасад - это синоним сервис локатора? :)

Так зачем это называть контрактами? Это обычные интерфейсы.. Их выносят вларавеле в отдельную папку.. Где то просто есть у тебя в пакете папка Respository и там лежит RepositoryInterface..

Тебе просто нейминг не угодил? Это странно

а где классы, его реализующие?

Да где угодно.. Посмотри как в симфони допустим сделаны модули..

Там сервисы зависят друг от друга и эта завсимость явно прослеживается в нейспейсах

Да где угодно.. Посмотри как в симфони допустим сделаны модули..

https://github.com/symfony/contracts

Да где угодно.. Посмотри как в симфони допустим сделаны модули..

а почему RepositoryInterface? почему не UserRepository?

а почему RepositoryInterface? почему не UserRepository?

Да похер не в этом суть

Да похер не в этом суть

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

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

И как это решит проблему?

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

Это не так. Он отдельный затем что бы была меньше связность

Это не так. Он отдельный затем что бы была меньше связность

это немного не так работает

Это не так. Он отдельный затем что бы была меньше связность

да. нужен отдельный. но не Contracts :)

Это не так. Он отдельный затем что бы была меньше связность

так вот именно.. Но она же все равно есть

Если ты делаешь пакет а там контракты ты все равно зависишь от этого пакета

если эти контракты юзаешь

в целом нейминг ларки вокруг некоторых частей, *ble аля authorizable/authenticatable и прочее вполне норм

Смысл их выносить тогда?

однако всякие RepositoryInterface архаизмы и пережиток прошлого

ERROR: S client not available

однако всякие RepositoryInterface архаизмы и пережиток прошлого

нет в ларке RepositoryInterface :)

интересно, если у ларки попросить через DI экземпляр Illuminate\Contracts\Auth\Authenticatable - она ведь реально сунет залогиненного юзера, да?

Смотрите, если у меня есть 2 сервиса.. UserService и Cart.. Где должны быть интерфейсы.. Это же бредово если интерфейсы у меня будут лежать в App\Contracts

https://github.com/Sylius/Sylius

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

сервисы имеют четкие зависимости

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

с интерфейсами к DTO - https://github.com/Sylius/Sylius/blob/master/src/Sylius/Component/Mailer/Model/EmailInterface.php нуну :))

Подскажите пожалуйста новичку в чем разница в записи 'middleware'=>'auth' и 'middleware'=>['auth'] ?

ни в чем

Подскажите пожалуйста новичку в чем разница в записи 'middleware'=>'auth' и 'middleware'=>['auth'] ?

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

Кстати вот как действительно лучше записывать?

Если 1 элемент?

Я все в массив пишу, чтобы везде одинаково выглядело

Я все в массив пишу, чтобы везде одинаково выглядело

Я тоже думаю так лучше но помню меня поправили типа если не нужен массив то и не делай массив

Типа излишне )

Тоесть в route::group для всех контроллеров отработает одинаково?

Но сейчас тоже массив на будущее делаю

Я тоже думаю так лучше но помню меня поправили типа если не нужен массив то и не делай массив

Экономия на спичках

Экономия на спичках

Согласен

Спасибо

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

круто быть тобой

тролль 79 уровня :)

-79

"Ваши строки, определённые при помощи ', а не ", будут интерпретироваться чуть быстрее, т.к. PHP ищет переменные внутри "..", но не '...'. Конечно, вы можете использовать это только тогда, когда в вашей строке нет переменных."

спасибо за информацию

это особенно важно после того как будет сгенерен опкод :)

У вас стоит перенос кода в редакторе, или вы с зажатым shift скролите?

зачем переносить код

лишние пробелы не укоряют интерпритацию

все в строчку писать профитнее

:) Да не, я не про оптимизацию, просто