Aquí no estoy para nada de acuerdo contigo. La jerarquia de movieclips es un composite, tanto como el objeto XML.
1- Los hijos *solo* se pueden crear y destruir a través del padre (createEmptyMovieClip,attachMovie,createClassObject,removeMovieClip...) 2- Todos descienden de una misma clase base, aunque algunos puedan utilizar subclases. 3- Hay branches y leaves (ramas y hojas) 4- Tienen un indice y se pueden ordenar a través de ese indice (depth) En cuanto a usar el _level0... Bueno, no es algo que se haga a la ligera. Si tu estas haciendo una aplicación sencilla con un MVC puedes tomar como view tranquilamente la jerarquia de movieclips. Es un composite, desciende de algun tipo de clase grafica, tiene un mapeo 1 a 1 con los elementos de interface. De todas maneras, lógicamente, meter datos en _level0 sin ton ni son a mi tambien me parece una mala practica. En una aplicación más compleja normalmente no lo haria, pero si el model es un simple gestor de parámetros no me cortaria ni un pelo :) Joseba Alonso www.5dms.com www.sidedev.net > -----Mensaje original----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En > nombre de Manuel de la Higuera > Enviado el: miércoles, 17 de noviembre de 2004 17:29 > Para: [EMAIL PROTECTED] > Asunto: RE: [ASNativos] > Singletons(eraRecuperarunavariablepasadaconloadMovieNum) > > De acuerdo, cada maestrillo tiene su librillo. A mí personalmente el > utilizar _level0 me parece una mala práctica y simplemente vela el uso de > una clase estática o de un singleton. Ya sabes que yo soy muy estricto > (hay > gente que me llama dogmático) en el uso de la terminología y *me niego* a > que se acepte la jerarquía de los MovieClips como un composite. Una vez se > pierde el carácter mitótico (i.e.: crear un hijo a partir exclusivamente > del > padre) se pierde también el "Composite". > > Un MovieClip, para crear un hijo a su imagen y semejanza, necesita de un > ID > de la librería --sí, vale que existe el hack del __Package, pero no es > built-in ni documentado-- o bien un duplicateMovieClip, que genera un > MovieClip idéntico sí, pero nunca podrá formar parte de los hijos de él > mismo. Asímismo, no puede haber movieclips independientes de _root. > > Ya conocía el link que has puesto --si no conociera los inconvenientes de > las cosas de las que hablo, sería muy poco ético por mi parte hablar de > los > pros--. Btw, gracias por compartirlo con la lista, merece la pena echarle > un > vistazo. > > M. > > > >-----Mensaje original----- > >De: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] En nombre de Joseba Alonso > >Enviado el: miércoles, 17 de noviembre de 2004 16:34 > >Para: [EMAIL PROTECTED] > >Asunto: RE: [ASNativos] Singletons > >(eraRecuperarunavariablepasadaconloadMovieNum) > > > > > >> _level0 viene a ser casi igual a nivel práctico que _global. > >No existe > >> casi diferencia entonces entre usar una clase estática o una clase > >> "normal", salvo en el uso de instancias. > > > >El uso de instancias es una razón suficiente ¿no? Vamos, las > >mismas que tiene el singleton sobre las clases estáticas. > > > >Yo muchas veces utilizo _level0 directamente como view cuando > >la aplicación es sencilla. Entonces instancio un pequeño model > >directamente ahí. A eso me refería. Al fin y al cabo toda la > >jerarquía de MCs que utiliza Flash es un composite. Luego > >podrías cambiar esa instancia por un subtipo sin preocuparte. > >Como la ampliación a internacionalización que comentabas. > > > >> > >> >Una cosa aparte que he leido sobre los singletons, y me parece > >> >interesante, es que tienen una gran pega. Normalmente los clientes > >> >saben demasiado sobre ella. Saben como se construye. > >> > >> Eso sólo ocurre cuando la implementación no es lo suficientemente > >> flexible. > >> Lógicamente es mucho mejor que la construcción de la instancia sea > >> invisible para sus suscriptores, pero eso depende del diseño de la > >> aplicación y no del Singleton en sí mismo. De hecho, en muchas > >> ocasiones se recurre a una clase que hace de Proxy para > >devolver la(s) > >> instancia(s) de un singleton/multiton, ya que aumenta la > >flexibilidad > >> de las clases que utilizan esas instancias. > >> El no hacer estos cambios en la flexibilidad podría desembocar en la > >> violación del principio de sustitución de Liskov[1]. > >> > >> >De esta manera Documento no tiene ni idea de cómo se crea un > >> >impresora (ni falta que le hace) que podria seguir siendo un > >> >singleton (o no) y la aplicación puede tomar la decisión sobre como > >> >se consigue la instancia. > >> > >> Estoy de acuerdo con ello, pero el caso que nos ocupa es una clase > >> totalmente dependiente de otra y no una agregación. No veo > >qué sentido > >> tiene evitar el getInstance() si es una clase final. > >> > >> Por favor, ilumíname. > >> > > > >No, era un tema aparte ("> >Una cosa aparte que he leido sobre > >los singletons" ). Lo habia leido y me había parecido bastante > >interesante comentarlo en este contexto. > > > >Igual ya lo habías leído, este documento me ha parecido > >interesante sobre el > >tema: > >http://www-106.ibm.com/developerworks/webservices/library/co-si > >ngle.html > > > >Un saludo, > > > >Joseba > > > >---------------------------------- > >Lista ASNativos:[EMAIL PROTECTED] > >http://www.5dms.com/listas > >---------------------------------- > > > > ---------------------------------- > Lista ASNativos:[EMAIL PROTECTED] > http://www.5dms.com/listas > ---------------------------------- ---------------------------------- Lista ASNativos:[EMAIL PROTECTED] http://www.5dms.com/listas ----------------------------------
