Mailing List
Home
Forum Home
Flash Pro
Subjects
Subject: RE: Firework Effect
Web Service Results
Flash Interface with 10mb xml file
AW: [Flashcoders] Switch/Case vs If/else
AW: [Flashcoders] Switch/Case vs If/else
Flash MX 2004 Sucks
Reading and displaying RSS feeds in Flash MX
Flash and QuickTime VR
Textfield prototype question
XML to Object help
Order of events per frame
MX2004 Dataset itemClassName
memory management removeMovieClip /
Event Dispatcher between classes
Help: MX 2004 How to script a print button to print the entire sli
ScrollPane component doesn 't auto update
setInterval bug identified and fixed
setInterval bug identified and fixed
Listener Object 's best practice
 
JSAPI MXML parser

JSAPI MXML parser

2004-05-01       - By Samuel R. Neff

 Back
Reply:     1     2     3  

Peter,

I've been thinking about this a lot but there's more to Flex than just
parsing MXML--which is what a lot of the run-time things are missing.

To implement MXML we'd need these features minimally:

1.  New components, particularly the containers.

2.  New base functionality, particularly the sizing rules (widthFlex etc).
This is run-time functionality.

3.  Create the document object for each MXML file for access by ID
regardless of movieclip hierarchy (ok, this is cake).

4.  Binding mechanism (Flash has the basics of this, just need to expand to
handle expressions)

5.  Descriptors.  This is a big performance feature of Flex (although no
Flex app looks like it has any performance features).  Flex doesn't just
build all the objects in an app, it creates an object descriptor hierarchy
and doesn't actually instantiate objects until the descriptor is referenced.
This is something like lazy instantiation.

6.   CSS parser.  No biggie, but Flex has a lot more CSS support than Flash
does.  I really wish Flash had it's level of support--it's disappointing
that Flash doesn't.

It's certainly feasible to write a C/C++/.NET/Java/Whatever program that
parses MXML and generates an FLA from it via JSFL.  It's just not a small
task to do it right and result in something really useful.

It's not really something you want to do all in JSFL even if it's possible
'cause JSFL really isn't geared towards large projects like that.  Besides,
if you write it in something else at some point you may be able to swap out
the JSFL export for a direct SWF writer and bypass Flash altogether.  Then
you'll end up with something like Snappmx.  :-)

Best regards,

Sam


-- ---- ---- ---- ---- ---- ---- ---- --
Blog http://www.rewindlife.com
TeamMM http://www.macromedia.com/go/team
-- ---- ---- ---- ---- ---- ---- ---- --




> -- --Original Message-- --
> From: Extendflash-bounces@(protected)
> [mailto:Extendflash-bounces@(protected)] On Behalf Of Peter Elst
> Sent: Saturday, May 01, 2004 4:57 AM
> To: Extendflash@(protected)
> Subject: [ExtendFlash] JSAPI MXML parser
>
> Hi guys,
>  
> After seeing the beta FileSystem JSAPI extension DLL in
> action I started
> thinking about the possibilities that this opens. What about an
> author-time MXML parser for the Flash IDE? This would certainly be a
> huge task to fulfill but could serve as a good alternative to the
> runtime parsing many are proposing now.
>  
> Just an early Saturday morning idea, would love to get some
> feedback on
> it :)
>  
> Cheers,
> Peter



__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Extendflash mailing list
Extendflash@(protected)
http://flashguru.co.uk/mailman/listinfo/extendflash_flashguru.co.uk