Un grand merci pour vos reponses, il est vrai que ma question portait plus sur la gestion des assets graphiques. J'ai pris l'habitude de charger mes graphiques placés dans un swf, mais la solution du swc parait également séduisante en tout cas vos réponses me permettent d'avancer. Je pense que le futur flash builder sera adopté massivement par la communauté des flasheur et se genre de question risque de fleurir sur les forum dédiés
encore merci et bon dev On 10 juil, 15:20, zwetan <[email protected]> wrote: > Salut, > > > Je viens de lire l'article sur l'applicationDomain, un grand merci. > > Je sais que zwetan a déjà répondu à cette question au travers d'un > > précédent post en expliquant qu'il utilise un swc, mais en dehors du > > fait qu'il faille charger le swf, quel est l'intérêt du swc sachant > > qu'il augmentera la taille du swf final ? > > Est-ce que l'intérêt se trouve dans le workflow ? > > En utilisant le même applicationDomain le swf s'utilise au final aussi > > simplement que le swc, non ? > > Bon dev à tous > > alors dans l'ordre > > le code est d'abord compilé en ABC (ActionScript ByteCode) > puis selon la cible > > 1) il est compilé vers un SWF > - ajout des headers propre au SWF > - ajout des symboles graphics / movieclip / etc. > > et ce SWF devras etre completement chargé en mémoire poru aceder > au code > > 2) il est compilé vers un SWC > > un SWF c'est comme un SWF, mais avec une difference de structure, > c'est come un zip > > SWC > |_ library.xml > |_ library.swf > > et une grosse difference qui est que on est pas obligé d'inclure > ou de loader tout le SWC piur en n'utiliser > qu'une petite partie > > tu peux tres bien avoir un SWC de 50Mo mais n'utiliser en fait que > 5Ko de bytecode > par rapport aux classes que tu veux utiliser dans ton SWF final > > quelques ajouts, avec Flex 4, Adobe ajoutera le asdoc dans le SWC, > donc ils seront encore plus gros, > mais pareil ca ne veut pas dire que tout le SWC sera inclu dans le SWF > final, uniquement une partie ou tout le bytecode. > > Au niveau du workflow > > utiliser Flex Builder, Flash Develop, Eclipse+FDT, > c'est tres bien pour ecrire du code, mais c'est tres pourri pour faire > du design > donc un workflow parmis d'autres (mais qui est pas mal) > est d'utiliser > > 1) le Flash IDE > tu definis tes symbols, tes anims etc. > le stage reste vide, tout est dans la librairie > > et tu coches par symbol > [x] exporter sur la 1ere frame > [x] exporter pour actionscript > > en donnant un nom d'export > > si ton appli est dans com.monappli > tu peux decider q ue le symbol mcBackground sera exporté en > com.monappli.ui.BackgroundUI > > au lieu d'exporte un SWF, dans les params d'exports tu coches en > plus > [x] exporter un SWC > > 2) dans FB / FD / FDT etc. > > tu ajoutes les SWC généré plus haut dans tes libs > > et cela te permet de faire des choses comme par ex > > package com.monappli.ui > { > public class background extends BackgroundUI > { > //... > } > } > > les assets du SWC se comportent comme des classes meme si tu les as > pas defini dans le code mais dans le FLA. > > c'est UNE maniere de faire parmis d'autres, mais perso je la trouve > tres pratique > le FLA est ouver peut-etre 1 fois ou 2 pour regenerer le SWC > > et le code depuis Flex Builder peut etre compilé des centaines de fois > tout en utilisant ces jolis assets fait dans Flash > > alors le SWC, il faut le considéré presque comme un SWF, mais plus > comme un "reservoir" > de classes et symbols, que l'on peut utiliser ou non > > et idealement on veut separer ces symbols et classes > > en general j'ai > /libs > |_ assets.swc //venant du FLA > |_ nom_de_la_lib.swc //venant de code AS compilé avec compc > > si j'ai une lib "toto" et que je dois travailler dessus en meme temps > que l'appli en cours, > cad que je dois modifier le code source constamment > > j'aurais plutot > > /lib > |_ toto > |_ FooBar.as > /libs > |_ assets.swc > > et des que la lib est stabilisee > > /libs > |_ assets.swc > |_ toto.swc > > et le ApplicationDomain n'a rien a voir avec tout ca :D > > dans l'article posté précédemment je parle de chargement de modules > SWF externes > > cad que ca, ca se passe au runtime, et ca donne plutot ce genre de > structure > > monappli.swf 50K > |_ fonts.swf 20K > |_ login.swf 80K > > je pourrais tres bien tout compilé dans un gros SWF (de 150K), > mais voila c'est une application dit modulaire > > cad que le SWF principal monappli.swf ne veut pas embeddé les fonts ou > une font, > il veut charger une des fonts dynamiquement > > par ex: > > if( lang == "en" ) > { > load( "en_arial.swf" ); //SWF de 50K} > > else if( lang == "jp" ) > { > load( "jp_arial.swf" ); // SWF de 2Mo > > } > > ou autre exemple, si la page HTML contient deja une session ID, on > retrouve les infos > de login de l'utilisateur et on le met "deja loggé", et on a pas > besoin de loader "login.swf" > > les explications sur l'ApplicationDomain servent principalement a > gerer ce genre de choses > > par ex une font dans un SWF externe, pour pouvoir faire un > Font.registerFont() il faut absoluement > faire un "import loading", si la class se retrouve definie en > isolation on ne pourra pas la reutiliser > dans toute l'appli > > idem pour un module de login, comme login.swf, la l'approche est > differente, > ce SWF est chargé en complete "isolation" et il communique avec le SWF > principal > par le biais de shared events ou de local connection, > on n'isole pas completement mais on isole suffisamment > pour qu'il n'y ait pas de collision avec certaines classes > > cela permet au SWF login.swf d'utiliser pureMVC as3corelibs etc. > sans que ces classes viennent polluer la memoire de monappli.swf :D > > mais en gros les "modules" ca permet de deleguer le boulot de chaque > dev sur son propre module, > et que tout puisse marcher ensemble meme si les styles de coding > different. > > enfin voila, j espere que je ne rends pas tout ca inbitable ;) > > zwetan --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/FCNG?hl=fr -~----------~----~----~----~------~----~------~--~---
