=)

У меня шаблоны имеют множественную иерархию

завязывать это на именах роутов такое себе

че там можно автоматизировать, мне интересно

В тестах удобно

завязывать это на именах роутов такое себе

Чё себе такое ?

Это охуенно

такое себе такое

такое себе такое

Писать прямые роуты, такое себе

Не уметь валидацию это такое себе

я на уровне рендеринга это конфигурировал

а вязать на имена это норм ... бля это охуенно

это более правильно ящитаю

роуты не должны хранить инфу о шаблонах

ясен красен

роуты не должны хранить инфу о шаблонах

Ау ты чего дядя, тут речь о другом

Ты не хранишь инфу о шаблоне, ты лишь обозначаешь текущий state

это и есть инфа о шаблоне

?

что бы твоя система знала где ты , что ты , и что ей делать с этим

какого хера у тебя стейт шаблонов на уровне роутинга делает)

когда ему место на уровне рендеринга, что логично

когда ему место на уровне рендеринга, что логично

Ты дурак ? =)

ясно

датвидания

Причём тут рэндринг вообще

Чет херню несешь фолли

в смысле херню

роуты могут меняться, имена нет

@F01134H а ты в вейкапп что ли?

ват

роуты могут меняться, имена нет

оке

Скажем ты что-то поменял в роуте, например добавил v2 какой-нибудь

тогда причем тут иерархия шаблонов, гениальный ты мой?

Ты ща бесплатно их вакансию ретвитил что ли?

И что ты во всех вьюхах будешь руками править?

тогда причем тут иерархия шаблонов, гениальный ты мой?

Вообще хз про что это

И что ты во всех вьюхах будешь руками править?

а перед тем как рендерить, никуда нельзя запихать, не?

Я про именованные роуты

надо в роутинг пихать?)

а перед тем как рендерить, никуда нельзя запихать, не?

Например дать имена?

Отличная мысль

Например дать имена?

заебись, связывать имена роутов с иерархией шаблонов

у нас же нет гибкого механизма респонсов

Крад ресурсы в бэкпаке так сделаны насколько я знаю

В смысле вот как простой пример: ссылка: site.com/dashboard Имя роута: module.dashboard.index исходя из этого я знаю что Область(Scope) - это модули, Сущьность(Thing) - это Дэшборд, Действие(Action) - это index,

Так что ты не один такой, да

Пацаны, вы тут про роуты заговорили

А как вы их называете

Я называю тип POST_Users_Delete

В таком формате

account.index, account.show

ДА выше предложил нормальную схему

Крад ресурсы в бэкпаке так сделаны насколько я знаю

# Route::group(['prefix' => 'admin', 'middleware' => ['admin'], 'namespace' => 'Admin'], function() # { # CRUD::resource('tag', 'TagCrudController'); # });

чет не особо похоже

А если пост запрос хочу в нейм обвернуть?

чет не особо похоже

Это что ты показал?

?

А если пост запрос хочу в нейм обвернуть?

мм?

Глянь на имена которые сгенерит

а, так там автоматом генерит

мм?

А не, я понял что-то типа account.update

ну да

раньше в название тоже добавлял метод, но последнее время отошел вроде от этого

насколько я знаю, речь шла про 'as' => 'profile', а не про uri роута

ERROR: S client not available

он сказал что пихать в них иерархию темплейтов - умно

ну да, про имя

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

короч нафиг

я, когда даю имена (не всгда) - ориентируюс на функционал за этим роутом

кактотак

это логично

ребят

с ноде жс кто хоть немного работал?

Ребята, с точки зрения органицации кода это правильно вызывать одно событие из другого? Есть сделка и по ней вносятся оплаты, вызывается собитие Payment, когда оплачена вся сумма сделки, то должно вызывать событие FullyPaid, это нормально проверять оплачена ли вся сумма внутри Payment и вызывать событие оттуда?

Господа, всем КУ! Подскажите пжлста как создать свою функцию сброса пароля.

со стандартным php artisan make:auth разобрался, но не до конца догоняю суть тритов

Направьте на нужнаю документацию или туториал?

нужную*

Трейты это пхп, а не ларавел

На пхпдок тебе

с ноде жс кто хоть немного работал?

+

Ребята, с точки зрения органицации кода это правильно вызывать одно событие из другого? Есть сделка и по ней вносятся оплаты, вызывается собитие Payment, когда оплачена вся сумма сделки, то должно вызывать событие FullyPaid, это нормально проверять оплачена ли вся сумма внутри Payment и вызывать событие оттуда?

Я бы сказал нет. Не надо делать методам больше одной ответственности

Проверки в свиче

повторяющиеся

это конечно гениальный код

Я бы сказал нет. Не надо делать методам больше одной ответственности

Тогда встаёт вопрос откуда вызывать FullyPaid, Payment вызывается из Deal::created(function() {...})

это конечно гениальный код

Свитч это уже признак говнокода, не?

да

Свитч это уже признак говнокода, не?

Смотря как использовать его.

Свитч это уже признак говнокода, не?

:)

Ребят случайно ни кто не подключал к себе в проект? https://github.com/viacreative/sudo-su

у меня выдает ErrorException (E_ERROR) No hint path defined for [sudosu]. (((

Пацаны, такой аопрос, как сделать чтобы Шторм нормально реагировал на Model::where()... Model::first() и т.п.

/** * @return Bot */ public function getBot() { return Bot::where('name', 'blogerparty_checker_bot')->first(); }

Сейчас так делаю