Организация приложения GUI
У вас есть JS callback в вашем ответе. Попробуйте удалить дополнительные переменные из вашего URL, например https://www.magellanprovider.com/ProviderSearchGateway/sessions/52229928/providers.jsonp?start=1&end=100, или с помощью регулярных выражений вырезать JSON из текста ответа.
3 ответа
Извините, что вскочил на этот вопрос настолько поздно, но ничто, я подразумеваю, что ничто не может разбить рассмотрение источника приложения, которое делает что-то подобное. (Я мог бы рекомендовать что-то как http://pida.co.uk, но существует много расширяемых wx+Python IDE там, поскольку это походит на то, что Вы делаете).
Если я мог бы сделать несколько примечаний:
передача сообщений не по сути плоха, и она не обязательно вызывает связь между компонентами, пока компоненты придерживаются интерфейсов.
общее состояние не по сути плохо, но я пошел бы с Вашим инстинктом пищеварительного тракта и использованием как можно меньше. Так как сама вселенная с сохранением информации, Вы не можете действительно избежать этого полностью. Я склонен использовать общий объект "Босса", который обычно является неодиночным элементом единственный экземпляр на приложение и ответственен за посредничество в других компонентах.
Для привязок клавиш я склонен использовать некоторую систему "Действия". Действия являются вещами высокого уровня, которые пользователь может сделать, например: "Сохраните текущий буфер", и они могут быть удобно представлены в UI кнопками на панели инструментов или пунктами меню. Так Ваши действия по созданию сценариев/плагинов, и регистрируют их в чем-то центральном (например, некоторый объект реестра - см. 1 и 2). И их участие заканчивается там. Вдобавок к этому у Вас есть некоторый сервис привязки клавиш, который отображает ключи к действиям (который он перечисляет из реестра на сессию или иначе). Таким образом, Вы достигли разделения кода сменной и привязки клавиш, разделения редактора и кода действия. Как добавленная премия Ваша задача "Конфигурирования ярлыков" или "Определяемых пользователем контурных карт" сделана особенно легче.
Я мог продолжить, но большая часть того, что я должен сказать, находится в кодовой базе PIDA, поэтому назад к моей исходной точке...
При рассмотрении MVC, Вы, вероятно, перемещаетесь в правильное направление. MVC, MVP, Пассивное Представление, Контролируя Контроллер. Это - все различные пути, каждый с их собственными за и против, выполнения, что Вы после. Я нахожу, что Пассивное Представление является "идеалом", но это заставляет Вас вводить слишком много виджетов в свои графические интерфейсы (т.е. IInterface). В целом я нахожу, что Наблюдение Контроллера является хорошим компромиссом.
В MVC Образцовый материал является общим состоянием информации.
Материал Управления является общим состоянием настроек управления GUI и ответов на щелчки мышью и этажерку.
Ваш угол сценариев может
1) Обновите Объекты модели. Это хорошо. Управление может быть "Наблюдателями" объектов модели и Представления быть обновленным для отражения наблюдаемых изменений.
2) Обновите Объекты управления. Это не настолько хорошо, но... Объекты управления могут затем внести соответствующие изменения в Модель и/или Представление.
Я не уверен, что проблема с MVC. Вы могли предоставить примеру более детального проектирования конкретные вопросы или проблемы?