#actionscript-3 #model-view-controller #design-patterns #user-interface #view
#actionscript-3 #модель-представление-контроллер #шаблоны проектирования #пользовательский интерфейс #Вид
Вопрос:
У меня есть приложение, которое проводит пользователя через набор шагов, настраивая продукт, скажем, около 10 экранов. С возможностью возврата назад, перехода к определенной точке и т.д. Мне нужно переходить между этими шагами, а также иметь доступные языковые переключатели в любой момент.
Я думал об использовании шаблона в стиле MVC, имеющего главное представление, которое принимает ‘следующее представление’ и изменяет его, удаляя старое.
Кажется раздутым иметь более 10 отдельных классов просмотра, использующих похожие компоненты для этой задачи, поэтому было интересно, какие еще существуют подходы, на которые я должен обратить внимание? или тот, который подходит для такого рода приложений
Комментарии:
1. Что плохого в наличии более 10 отдельных представлений? Наличие 1 большого класса с несколькими состояниями кажется мне хуже
2. Я думаю, ничего, кроме того, что кажется, что это не лучший путь вперед. Поскольку два представления могут отличаться не более чем небольшим количеством текста и несколькими параметрами. Но, я полагаю, было бы проще и понятнее разработать.
3. Взгляните на шаговый компонент здесь : lab.kapit.fr/documentation/klovis/prod/klovis-flex-core/asdoc /…
4. классные приветствия выглядят полезными
5. 1 @Florian. 10, или 20, или 30 отдельных классов просмотра, на мой взгляд, подойдет. Каждый должен наследовать или реализовывать стандартный набор методов, максимально разделяя функциональность. Но — учитывая, что у вас есть отдельное содержимое, каждое из которых требует особого поведения на каждой странице / представлении, кажется очень разумным разделить на отдельные классы (и гораздо предпочтительнее, чем один класс god, который обрабатывает is all). Я следовал этому точному шаблону в прошлом с разумным успехом.
Ответ №1:
Прежде чем разделять ваши представления, сначала подумайте, что у них общего.
Моим первым побуждением было бы создать класс представления и задать необходимые свойства для самого представления, а именно затухание между экранами и все остальное, что вам нужно, что связано с дизайном.
Вы говорите, что пользователь будет настраивать продукт, поэтому вы можете захотеть создать класс конфигурации исключительно для этой цели. Будьте осторожны, чтобы не вводить слишком большую зависимость между вашими объектами.
Класс конфигурации не должен знать слишком много о классе представления, более конкретно о способе его отображения.
Сложно рассказать больше, не зная вашего проекта, но идея заключалась бы в том, чтобы разделить представление и данные, посмотреть, что общего у ваших объектов, а затем использовать переменные или другие объекты для придания большей конкретности.
Комментарии:
1. Хорошо, спасибо, я думаю, что у меня все в порядке с головой — я начал играть с robotlegs прошлой ночью, и я думаю, что я просто начал усложнять вещи для себя в этом простом приложении.
Ответ №2:
Для этого я использовал фреймворк Gaia Flash. http://www.gaiaflashframework.com
Это видео введение http://tv.adobe.com/watch/fitc/gaia-framework-for-adobe-flash / должен дать вам представление, почему я думаю, что это сработает для вас.