Python-сообщество

Доброжелательные коллеги.

Так получилось, что написал http://asvetlov.blogspot.com/2011/02/blog-post_05.html и http://asvetlov.blogspot.com/2011/02/blog-post.html

Критика приветствуется.

чтобы не гадить в комментах позанудствую тут:
long pulling -> long pOlling (вроде бы это имелось в виду)
piramid -> pYramid

Исправил. Спасибо.

В разделе о языках разметки забыли, наверное самый успешный сейчас Mozilla - XUL. Впрочем, вы оговорили, что не особенно внимательно следите за этим направлением. Жду продолжения.

С XUL дела не имел никогда. Посмотрю, спасибо.

Вторая часть “графического интерфейса”.

http://asvetlov.blogspot.com/2011/02/blog-post_07.html

Все еще хожу по избитым дорогам.

Андрей Светлов
Вторая часть “графического интерфейса”.
http://asvetlov.blogspot.com/2011/02/blog-post_07.html
Все еще хожу по избитым дорогам.

Прямо развернутый ответ на вопрос, что я недавно задавал в разделе GUI :)
Понравилась мысль о том, чтобы рассматривать GUI модели как адаптеры.

Дальше планируется больше.
Я в свое время на проблемах GUI и моделей душевно потоптался.

Третья часть рассуждений о GUI: http://asvetlov.blogspot.com/2011/02/blog-post_08.html

Андрей Светлов, не совсем вкурил, чем принципиально отличается MVC от MVP.

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

Я так понимаю в этом случае разница в том, что Presenter занимается обновлением модели, а не View.

Андрей Светлов
Для таких сценариев представление должно выступать в роли наблюдателя (Observer) для интересующих частей модели, приводя вид в соответствие модели при каждом изменении последней.

В MVC есть понятие Editor, он и решает эту задачу (почему-то ни в одной статье о MVC я так и не встретил этого компонента модели, а он важен).