Да ну? Третья строчка.
Этот код работает (хоть и вышло далеко не с первой попытки).

И правда, проморгал.
Красивый у вас код, к слову :)

Zubchick
Красивый у вас код, к слову :)

Годы тренировок :)
И много-много мегабайтов чужого красивого и разного кода прочитал, да…

regall

Андрей Светлов
Нечто вроде современного подхода к таблицам с редактированием ячеек.

Я для себя представляю Editor, как редактор текста. То есть он нужен, чтобы текст не сохранялся после каждого введенного символа, а хранился до нажатия кнопки сохранения. В принципе, те же яйца только в профиль.

Откровенно говоря, не знаю что подразумевали первые авторы MVC.

Исхожу из того, что имеем сейчас.

На форме есть wx.TextCtrl - пароль пользователя.
Можно подписаться на события:
- ввод символа
- нажатие <Return>
- жмаканье на <Tab>
- потерю фокуса

Редактора как такового нет.

В зависимости от того, что желает заказчик/аналитик/пользователь, - нужно обновлять модель на каждый чих (показывая, например, достаточно ли хорош пароль чтобы его не сломали за десять секунд), - или игнорировать все эти действия до момента клацанья по заветной кнопке “Запомнить пароль”.

Так или иначе презентация работает с нашим TextCtrl, который знать не хочет о модели и контроллере.

Если так удобно программисту - он сделает сложный синхронизатор.
Я не раз упоминал этот термин в статье при том, что в первоисточниках такого нет.
Этот синхронизатор будет обрабатывать ввод GUI до тех пор, пока не решит что нужно переслать пароль в модель.
Если логика сложная - тогда это Editor.
Только вот какая беда - сложная логика должна прописываться в модели, а не в Controller/Presenter.
Получается, модель у нас двухуровневая:
- вяло ожидает новых изменений в поле “пароль” (рисуя красным цветом “нестойкие”). Проверка на “пушистость пароля” - это ведь задача бизнес-логики, которая целиком находится в модели.
- и бодро изменяет базу данных после нажатия на “изменить пароль”.

Возникают неприятные вопросы вложенности и транзактности моделей, на которые MVC (равно как и MVP) ответа дать не могут - не их компетенция.

Андрей Светлов
Возникают неприятные вопросы вложенности и транзактности моделей, на которые MVC (равно как и MVP) ответа дать не могут - не их компетенция.

И не должны давать. Это уже попахивает особенностями реализации. Модель разработки задает каркас, а если пытяться углубляться и создавать рекомендации на все возможные комбинации и вариации бизнес-логики приложения, - можна очень далеко зайти и оттуда не выйти…

Андрей Светлов
Откровенно говоря, не знаю что подразумевали первые авторы MVC.

Я так понимаю редактор задумывался как некоторый буфер, снижающий количество запросов на изменение модели с целью оптимизации приложения, так как врядли в конце 70-х программисты задумывались об интерактивной проверке пароля на сложность по мере ввода символов, как ты выше описал, и так как, судя по всему, эти люди дальше модель не развивали, она уткнулась в реалии современности, и оказалась не готова к ним. Поэтому в контекстве задач, которые возникают перед программистами сейчас, модель 30-с-чем-то летней давности, конечно же, не имеет ответов на множество вопросов.

regall

Андрей Светлов
Возникают неприятные вопросы вложенности и транзактности моделей, на которые MVC (равно как и MVP) ответа дать не могут - не их компетенция.

И не должны давать. Это уже попахивает особенностями реализации. Модель разработки задает каркас, а если пытаться углубляться и создавать рекомендации на все возможные комбинации и вариации бизнес-логики приложения, - можно очень далеко зайти и оттуда не выйти…

Это - не вариации. MVP - тупой. Берет ввод пользователя, проталкивает его в модель и меняет вид в ответ.

А вот сложносочиненные модели по настоящему интересны!

Андрей Светлов
Это - не вариации. MVP - тупой. Берет ввод пользователя, проталкивает его в модель и меняет вид в ответ.
А вот сложносочиненные модели по настоящему интересны!

Верно. Я это и пытался сказать, может не совсем верно выразился, точнее совсем неверно. Как-то сложно с подбором слов, час ночи и веселый день с доблестным омоном в офисе =)