NO
Ctrl + Click по имени метода в Шторме позволит вам найти все вызовы метода в проекте. Ctrl + Click по имени класса - все обращения к этому классу. Удобно и очень просто.
Size: a a a
2020 May 02
ПГ
Почему вы решили, что без событий возможен только подход "всё говно храним в одном месте"?
Я вам написал задачу, вы описали ее решение как написать по методу на каждый чих в сервисе. Это не значит все говно в одном месте?
NO
Я вам написал задачу, вы описали ее решение как написать по методу на каждый чих в сервисе. Это не значит все говно в одном месте?
"вы описали ее решение как написать по методу на каждый чих в сервисе" Нет.
NO
Код в любом случае будет где-то храниться, в любом из ваших классов, куда вы его определите.
Использование событий VS прямой вызов - разница только в способе вызова этого кода.
В первом случае вы триггерите событие, во втором случае обращаетесь к коду напрямую через вызов метода.
Использование событий VS прямой вызов - разница только в способе вызова этого кода.
В первом случае вы триггерите событие, во втором случае обращаетесь к коду напрямую через вызов метода.
NO
Давайте уже перейдём к конкретным примерам и закроем тему )
А то по кругу бегаем, мне очевидно что вы меня не понимаете...
А то по кругу бегаем, мне очевидно что вы меня не понимаете...
NO
Под конкретным примером я имею в виду код, конечно же, а не словесное описание задачи.
ПГ
Код в любом случае будет где-то храниться, в любом из ваших классов, куда вы его определите.
Использование событий VS прямой вызов - разница только в способе вызова этого кода.
В первом случае вы триггерите событие, во втором случае обращаетесь к коду напрямую через вызов метода.
Использование событий VS прямой вызов - разница только в способе вызова этого кода.
В первом случае вы триггерите событие, во втором случае обращаетесь к коду напрямую через вызов метода.
Ну это у вас только сейчас свелось все к тому, что разница только в вызове. До этого я только слышал, что эвенты плохо и запутывают. Так выходит их плохо использовать или нет? Что мешает в месте регистрации эвента нажать на контрл и перейти к нему? А в бутстрапе посмотреть какие навешаны листенеры на него. Ну а доводы «сам дурак, иди учись» такое себе. Изначально я просто хотел услышать в чем же минусы использования эвентов, доводов мало. Да, юиишные эвенты могут вызывать проблемы.
NO
Прошу прощения, что недостаточно внятно выразил свою мысль в начале дискуссии. Сэкономили бы время...
NO
"Плохо и запутывают" как раз потому, что способ вызова неявный.
NO
"Что мешает в месте регистрации эвента нажать на контрл и перейти к нему? А в бутстрапе посмотреть какие навешаны листенеры на него"
Что мешает НЕ делать вызов через события и НЕ создавать себе и другим больше работы? )
Что мешает НЕ делать вызов через события и НЕ создавать себе и другим больше работы? )
NO
Я много раз видел, когда какой-то приём или подход использовали только "потому что прикольно". Разработчик увидел что-то новое и давай "играться", прикольно же. Это нормально, для получения опыта )
V
Чет туплю. Есть форма, и там поле. Нужно в одном случае сделать его required, в другом нет. Как это прописать в rules?
NO
Примеры уместного использования событий из моей практики, я приводил, напишу ещё раз )
1. Когда все компоненты кода общаются исключительно через события. В Qt (C++) так сделано, и там это очень классно упрощает код )
2. Когда вы пишете универсальный компонент или фреймворк, и захотели дать возможность простого расширения функциональности. Если точек интеграции немного, то события — хороший способ. Достаточно прицепить пару обработчиков к событиям компонента, и компонент уже интегрирован в систему.
Увидев такие примеры использования событий, разработчики иногда завязывают своё собственное приложение на события, и прогорают на этом...
1. Когда все компоненты кода общаются исключительно через события. В Qt (C++) так сделано, и там это очень классно упрощает код )
2. Когда вы пишете универсальный компонент или фреймворк, и захотели дать возможность простого расширения функциональности. Если точек интеграции немного, то события — хороший способ. Достаточно прицепить пару обработчиков к событиям компонента, и компонент уже интегрирован в систему.
Увидев такие примеры использования событий, разработчики иногда завязывают своё собственное приложение на события, и прогорают на этом...
ДК
Чет туплю. Есть форма, и там поле. Нужно в одном случае сделать его required, в другом нет. Как это прописать в rules?
Либо разные формы либо сценарии
OK
Чет туплю. Есть форма, и там поле. Нужно в одном случае сделать его required, в другом нет. Как это прописать в rules?
when использовать в правиле
OK
Но лучше, как сказали выше, разные формы юзать
V
Oleg Kuzmenko
when использовать в правиле
не хочется поля копипастить
NO
Чет туплю. Есть форма, и там поле. Нужно в одном случае сделать его required, в другом нет. Как это прописать в rules?
Сценарии не рекомендую, лучше сделать две формы. А для чего используется форма, что там вводится?
V
Сценарии не рекомендую, лучше сделать две формы. А для чего используется форма, что там вводится?
а что с сценариями не так? Обычная форма на пяток полей, при апдейте одно из них не нужно
NO
Что заполняется в форме? Это регистрация, логин, редактирование CRUD, онлайн-заявка?