I see your point. I would say though that we won't get rid of
Object.registerClass anytime soon, and that any view that is meant to be
compiled in MTASC include that line. I'm using a mixed Flash IDE/Fame
environment where the designers create the views in the IDE so they
don't have to touch the code at all, then hand to me and compile and
happily continue working in Eclipse. But sometimes for whatever reason
it will link perfectly well with the library items when I attachMovie to
place the views on stage, and other it will fail, but with an static var
linker = Object.registerClass('Whatever', Whatever) in there that solves
the issue every single time. So I'd make it a best practice to always
include the Object.registerClass anyway if ever by any chance some part
of the project has to tun through the IDE.
Patrick
Aral Balkan wrote:
Hi Patrick,
I'm not so sure about making the entry point a movie clip. In my
movies I always create a controller and THEN from the controller
create the first view.
This is definitely a valid way of doing things. The advantages I see
with making the entry point a movie clip (or Application form) is:
* As the article states, it provides a natural (at least for Flash)
entry-point as the Application Form is loaded and (in Flash) its
onLoad() is called automatically. No need for a separate static main()
method (as is necessary in Java applications.) In Flex, you override
init() and listen for the childrenCreated event and handle
initialization there. Which brings me to the second (big) advantage:
* Works the same way in Flash, Flex, MTASC/Swfmill, etc. and with ARP.
There's a real advantage to being able to migrate between Flash/Flex
and keep the same code/workflow.
Aral
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
