да и по поводу событий тоже сходимся во мнениях. Я может разве что больше делал упор на недостатки событий. Потому что ТС их как-то слишком превозносит. Т.е. уведомления от компонентов это хорошо, тем более что речь идет о библиотечных компонентах. Но компоненты, рассчитанные реагировать на события... я такого еще не видел, или не припоминаю. Во-первых, это навязывает наличие Mediator'а. Но даже если он предоставляется фреймворком, думаю, такой подход не всегда подойдет, скорее для простых случаев. А так, да, события бывают уместны, а бывают не уместны...
|
Сообщение от Panzermaus
|
Кроме того, в сложных случаях может выясниться, что некоторое событие возникает не очень во время и надо как-то переделать эту схему взаимодействия.
А вот это чегтовски серьезное возражение!
|
помню когда-то пытался кастомизировать TextBox в Delphi, перехватывал события от клавиатуры, но так и не добился, чтобы оно работало как надо. Но может они либо на это не рассчитывали, либо неудачно как-то организовали все это дело. Там правда, наверняка, использовался стандартный элемент управления Windows, так что все еще сложнее. Но это так, вспомнилось, да и деталей уже не помню
Или есть допустим схема с какими-то компонентами и модель. Модель обновляется и сообщает об этом компонентам. И тут я понимаю, что для какого-то компонента, нужно предыдущее состояние знать, а модель-то уже изменилась. Ну я сначала сделал еще одно событие beforeUpdate. А потом просто решил запоминать в компонентах нужную информацию (типа локальная модель). Ну т.е. можно считать, что совместил модель и компоненты, соотношение один-к-одному, так что нормально.
Правда я к тому же до этого считал, что модель в DOM хранить можно (типа по состоянию DOM все нормально выясняется). Зачем еще дублировать в javascript-объекте? Оказалось лучше дублировать. Так вот в результате я получил более простое и понятное решение, чем с "большим MVC" и большим количеством событий