Thank you so much for sharing your thoughts! How dynamic is that?! Well, I had 2 reasons for asking:
1. For good reasons, Flexbuilder is for the application/RIA-perspective, although you are able to, of course, animate whatever you want with MXML/AS3, you can´t handle this the way you did in the Flash IDE. Some of you were talking about workflow. Well I think it is not unusual, that during a project there are designers involved, that used to know about using the timeline ... So will one be happy with just importing Flash-IDE-made SWFs into Flex?? It is just about how to connect those two perspectives. 2. For me it is just the feeling, that there is something missing inbetween. I thought, that - if I decided to start with such a thing - maybe the best way should be using JSFL for what the Flex help says: that you could use Flash MX for building SWCs that could be used with custom tags in MXML (see "About the Flex coding process" in Flex help. ... so maybe JSFL is for building SWCs from everything in a FLA document and this idea is somehow derived from what Adobe tells us :-) That having written, I am still not shure if that should/could be done in a real world. Kind regards _____ Arne ----- Original Message ----- From: Tim Scollick To: Open Source Flash Mailing List Sent: Tuesday, July 11, 2006 6:44 PM Subject: Re: [osflash] FLA2MXML per JSFL - any thoughts? John, I'm just as confused. The only thing that I came up with was to maybe have a group of components that matches Flex's controls (Button, TileList, etc). You could lay a group of those components out and use component parameters that corresponds to a Flex property. Once you were finished the layout process, you could run the JSFL and voila, you'd have your mxml which you could then use with Flex, adding DataProviders, scripts, etc. Of course, you'd also have to be able to import from mxml into an .fla or the workflow would be one directional. Is this what anyone else had in mind? Tim On 7/11/06, John Grden <[EMAIL PROTECTED]> wrote: I'm sorry to be the noob on the block, but how does this work out practically? I mean, if you have an FLA with movieclips that have movieclips that have movieclips embedded blah blah blah, how's that worked out in mxml? An mxml file for each movieclip? Ok, I can see that, then you have to come up with some logic for packages based on the movieclips relationships? what if the movieclips aren't bound to a class? where do you park those? I mean, you'd have to create some package/class for each right? On top of all that, how would you account for movieclips that don't show up until frameX? Would that just be a "state"? Are you suggesting a full FLA conversion no matter how wacky it is or are you thinking just certain types of FLA's that follow some sort of pattern/guideline? And although it sounds like fun, what'd be the major benefit of having something like this? Just the ability to compile with the new / free / fast compiler? And how would it be apart of someone's work flow? IE: Do I have to export everytime I make a change in the FLA, then compile? Or, do I create/get the FLA, convert via JSFL command, then edit within the mxml after that point? if it's scenario #2, then what happens to the FLA and it's library of assets (bitmaps, sound, flv)? do you export all of them out, then embed for the application to use? Sounds like fun, and would be interesting to see, but not sure that starting from scratch wouldn't be better/easier. I mean, sounds like if Flasc could work to be used with the new compiler of MTASC, that'd pretty well help out with the problem that this might solve. Sorry, just thinking off the top of my head, it DOES sound like fun ;) On 7/11/06, Michael Stuhr < [EMAIL PROTECTED] > wrote: Ralf Bokelberg schrieb: > Nice idea, but the question is, what to do with the resulting mxml? send it to the free compiler, and lets see what results we get :-) point is: the free compiler needs a layout tool like flex has one. it's a 'nische', and if it isn't too complicated one should try. micha _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org -- John Grden _______________________________________________ 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 _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
