> Por otro lado, no entiendo muy bien que por ejemplo, si la primera > "escena" > tiene el login, el mvc/escena deba gestionar únicamente el login ¿no > es aceptable que también gestione el paso a la escena siguiente? ¿o > debe gestionar un cometido estrictamente en aras de la claridad > conceptual de cada clase? Porque por otro lado, en esa escena también > hay un panel de información, se cargan dinámicamente datos de la > aplicación que tienen una correspondencia visual (identidad > corporativa, báners...) ¿debería hacer clases para cada cosa?
Hombre, la estructuracion de clases, sobre todo cuando estas aprendiendo, es algo muy personal, el probar diferentes configuraciones te dará la clave para tu "metodo perfecto" pero en el caso del "login" gestionando el paso al estado siguiente tiene algunos problemas que te puedo ir adelantando. Lo primero, la gestion de cambio de estado puede implicar muchas cosas que pueden necesitar todos los cambios de estado en cualquier parte, por ejemplo, un preload, un cambio de titular, la selección de un elemento del menu principal...etc. Toda esa gestion seria mucho más eficiente y menos liosa en el controlador "padre", porque según vas avanzando en el proyecto es muy posible que el cambio de estado implique cada vez mas y mas cosas. Por ejemplo imaginate que mas tarde pones la opcion de "recordar usuario", en ese caso la proxima vez que se inicie, ya no necesitarias cargar el estado de login, sino que pasarias directamente al siguiente... Tambien esta lo que dices de la claridad conceptual de la clase, a mi no se me ocurriria más tarde buscar el codigo que hace el cambio de los diferentes estados del usuario dentro uno de los estados. Este deberia preocuparse solo de si mismo, no del resto de estados. > > Yo lo que suelo hacer es que reservo clases digamos de gestión de la > aplicación y hago otras (normalmente extienden > MovieClip) para cuestiones visuales de intractividad o animación y > normalmente son muy simples. De estas últimas puede haber muchas y no > me importa demasiado pero de las primera, estoy más cómodo si son > pocas. Quizá no es la opción más ortodoxa y finalmente es mejor ser > estricto con la metodología de clases que gestionen problemas muy > concretos pero esa es una meta por alcanzar... Yo normalmente, en web normales (no muy complicadas) suelo hacer casi seguro 5 grupos de clases: Clases de control: Controladores para las vistas. Son Singletons, es incompatible tener dos clases controlando la misma cosa. Clases de vista: Representan los diferentes estados del usuario, normalmente corresponden a las secciones de la web excepto una, la principal que corresponderia al "todo", el MovieClip principal. Todas estas clases las hago extender de MovieClip, esto ya es una preferencia muy personal mia, mi "framework" personal esta contruido asi, hay gente que usa composicion. Clases de servicio: La capa de acceso a datos. Se encargan de leer ficheros XML, hacer peticiones al servidor..etc. Normalmente las usan las clases de modelo. Clases de modelo: La logica de la aplicación, usan las clases de servicio para obtener y almacenar la información. Clases de UI: Son las clases que controlan los diferentes elementos de interface: botones, menus, scrolles, visores de medias...etc. Si su funcionalidad es más complicada, los separo en otro MVC. Normalmente se inician de la siguiente manera: Lo primero se inicia el view principal, esto es así porque esta directamente colocado en la linea de tiempo. Consigue una referencia a su controlador por el metodo del singleton y llama a 2 metodos: Uno registerView() para que el controlador tenga una referencia a la vista y (si es necesario) instancie el modelo y se lo pase de vuelta a la vista. Y luego llama a uno initialize() que inicializaria la aplicación principal, por ejemplo, para cargar la primera seccion. Esta a su vez sigue el mismo proceso, se instancia la vista (con un attachMovie, loadMovie o un gotoAndStop), consigue la referencia a su controlador y lo inicializa. En esa vista de la seccion, pueden ocurrir 2 tipos de eventos probocados por el usuario: eventos que maneja el controlador de esa vista o eventos que el controlador de esa vista no puede manejar y pasa al controlador de aplicación, como por ejemplo, el cambio a otra seccion. De todas maneras, como he dicho al principio, esta es *mi* metodologia, probablemente esto pueda cambiar en el modo que montan las aplicaciones otras personas. Lo mejor es que tu mismo vayas probando unas y otras y te quedes con la que mas te guste. Por cierto, estaria bien si algun otro comenta como lo monta el, siempre es bueno tener más puntos de vista :) Un saludo, Joseba Alonso www.5dms.com www.sidedev.net J ----------------------------------------------------- ASNativos www.5dms.com subscripciones/desubscripciones http://asnativos.5dms.com -----------------------------------------------------
