Non posso dirti nulla sulla migrazione dei componenti di terze parti. Non uso quelli che hai menzionato.
Posso dirvi, tuttavia, che non sarà possibile caricare semplicemente il progetto esistente in Flash Builder 4, modificare l'SDK in 4.0 e aspettarsi che ricompaia. Un numero enorme di cose è cambiato in Flex 4, spesso in modo incompatibile.
Ora avete due librerie di componenti parallele, Spark e MX. MX è la vecchia libreria di componenti Flex 3, a volte chiamata Halo, anche se tecnicamente è solo il nome della skin di default. Spark è la nuova libreria di componenti Flex 4, che sostituisce solo parzialmente MX.
Interagiscono. Puoi utilizzare entrambi in un'unica app e puoi fare cose come mettere componenti Spark in contenitori di layout MX come ViewStack. Ci sono anche divisioni naturali in un'applicazione in cui è possibile avere una parte usando Spark, l'altra MX, senza preoccuparsi dei problemi perché non interagiscono a livello di interfaccia grafica. Le finestre di dialogo sono così, per esempio.
Il motivo per cui hanno fatto tutto questo è supportare questo nuovo materiale per lo skin che hai sentito: Flash Catalyst, FXG e tutto il resto. Se usi la skin Halo di serie, non vedo che Spark ti importi, a parte il fatto che è The Future.
(a parte: Che cos'è la sintassi Markdown per ottenere il Wizard-of-Oz boomy effetto eco?)
Joan Lafferty (Flex SDK Quality Lead) ha un articolo di valore, Differences between Flex 3 and Flex 4. Su page 4, ha una tabella che elenca i componenti Flex 3 MX che non sono stati sostituiti dai componenti Spark in Flex 4. La maggior parte di questi non ha un aspetto proprio, come lo Accordion, quindi non è necessario scansionarli o cose come finestre di dialogo, come Alert. (Dovresti leggere il resto dell'articolo. Copre le cose che non sono, perché non ho ancora trovato tutte le differenze.)
Parlando di pelli, solo due delle pelli MX di Flex 3 sono ancora supportati in Flex 4. Le skin MX più colorate sono sparite, anche se c'è un nuovo set di skin colorate basate su Spark che mostrano alcune delle cose che puoi fare con FXG e così via. Se ti è piaciuto davvero uno di quelli che hanno rimosso, puoi senza dubbio ricrearli in cima a Spark, ma non è disponibile immediatamente.
Molte cose sono state renamed e alcune sostituzioni Spark per i componenti MX hanno interfacce diverse e quindi hanno different names. Ad esempio, per spostarti interamente su Spark, dovrai modificare i tuoi VBox e portarli a VGroup s. Ci sono molte piccole differenze fastidiose come quella.
A causa di tutta la doppia cosa libreria GUI, Adobe si sono trovati con un gruppo di tag MXML come <Script> e <Style> che non sono in realtà parte di MX, che funzionano altrettanto bene per Spark. Piuttosto che avere un set duplicato di tag, li hanno spostati in un nuovo spazio dei nomi XML. Questo è un problema per coloro che eseguono la migrazione a pezzi delle app basate su MX esistenti, perché significa che stai ancora usando l'alias mx per la libreria dei componenti MX, quindi tutti questi tag comuni a entrambe le librerie devono essere rinominati. Il nuovo spazio dei nomi XML predefinito per questi tag è fx, quindi ogni <mx:Script> deve essere rinominato in <fx:Script> e così via. L'IDE non fa questo per te durante l'importazione del progetto. Li trovi appena uno per uno mentre cerchi di far costruire il tuo progetto importato.
Se stai pensando di trasferirti interamente a Spark, puoi evitare un po 'di dolore qui. Invece di accettare l'alias dello spazio dei nomi predefinito fx nei tag non MX, è possibile lasciarlo continuare a utilizzare mx, poiché non è necessario per MX, e Spark utilizza s come predefinito.
Il primo compito dopo l'installazione di Flash Builder 4 dovrebbe essere quello di generare un nuovo progetto per poterlo studiare e copiare e incollare elementi come queste dichiarazioni dello spazio dei nomi.
Un'altra ricaduta nell'intero MX vs. Spark e nel disordine dei namespace è che il tuo CSS potrebbe aver bisogno di essere modificato. Flex ha un'estensione non standard CSS per questo, che assomiglia a questo:
@namespace mx "library://ns.adobe.com/flex/mx";
mx|Application {
....
tutti gli URL dello spazio dei nomi sono cambiati sia tra Flex 3 e Flex 4, e in almeno un caso cambiato di nuovo durante il processo Flex 4 beta.
http://www.adobe.com/2006/mxml è ora http://ns.adobe.com/mxml/2009 library://ns.adobe.com/flex/halo è ora library://ns.adobe.com/flex/mx
La forma local() per specificare i nomi dei font incorporati con il loro nome comune in CSS non funziona più. È necessario utilizzare il modulo url() e indicare il percorso del file del carattere.
Una trappola da cui fare attenzione qui è che questo significa che se si incorporano più varianti di un singolo carattere (ad esempio pesi normali e grassetti) il codice precedente fa riferimento allo stesso nome di carattere, ma il nuovo ne indicherà due file diversi perché i due pesi non sono nello stesso file .ttf o .otf. Ad esempio, questo:
@font-face {
src: local("Verdana");
fontFamily: VerdanaEmbedded;
fontWeight: normal;
}
@font-face {
src: local("Verdana");
fontFamily: VerdanaEmbedded;
fontWeight: bold;
}
deve essere cambiato a questo:
@font-face {
src: url("/Library/Fonts/Verdana.ttf");
fontFamily: VerdanaEmbedded;
fontWeight: normal;
}
@font-face {
src: url("/Library/Fonts/Verdana Bold.ttf");
fontFamily: VerdanaEmbedded;
fontWeight: bold;
}
In Flex 3, il compilatore intuibile quali file due caratteri .ttf il codice precedente si riferisce base all'attributo fontWeight. In Flex 4, il compilatore ti fa dire esplicitamente.
Se si incorporano i caratteri nell'applicazione e si continua a utilizzare i controlli MX, è probabile che il testo scompaia o ripristini il carattere predefinito. Questo perché, per impostazione predefinita, Flex 4 utilizza un meccanismo di incorporamento di font diverso sotto il cofano per supportare il miglior motore di rendering dei font in Flash Player 10. Per incorporare un font nel modo precedente in modo che i vecchi controlli MX possano ancora utilizzarlo, è necessario impostare l'attributo CSS embedAsCFF su false.
Il meccanismo degli stati è completamente diverso. Questo codice Flex 3:
<mx:State name="alternate">
<mx:SetProperty target="{myField}" name="editable" value="false"/>
</mx:State>
....
<mx:Form ...>
<mx:TextInput id="myField"/>
....
</mx:Form>
diventa presente in Flex 4:
<mx:State name="alternate"/>
....
<mx:Form ...>
<mx:TextInput id="myField" editable.alternate="false"/>
....
</mx:Form>
Il nuovo modo ha più senso per me, dal momento che mette tutti i singoli stati componenti nel tag componente stesso, invece di in alto nella parte superiore del file MXML in un verboso blocco <mx:State>, ma il porting al nuovo meccanismo è un po 'macabro. La conversione non è automatizzata dall'IDE, anche se potrebbe davvero esserlo.
Alcuni tag non sono più consentiti come figli diretti del tag <Application>. Questi rientrano in diverse categorie: validatori, effetti, ecc Si hanno ora di confezionare questi in su in una nuova <fx:Declarations> tag, in questo modo:
<fx:Declarations>
<mx:Dissolve id="myTransition" duration="100" target="{this}"/>
</fx:Declarations>
C'è una nuova opzione di progetto in Flash Builder che permette di continuare a utilizzare il Flex 3.5 SDK da solo, senza nessuna scintilla, per facilitare la migrazione. Questo va bene per i test iniziali, ma ad un certo punto si vuole andare avanti, a quel punto si deve fare i conti con quanto sopra.
Anche il nuovo compilatore non mi sembra molto più veloce. Non l'ho messo a confronto, sto solo andando a sentire, che è quello che conta davvero per me, dal momento che mi fa ancora sentire la testa sulla mia scrivania. :) Certamente non sta usando gli altri 7 core nella mia scatola di sviluppo. Grrr.
La scintilla vale tutti questi problemi per portarla ad esso? – Amarghosh
Ho modificato quanto sopra per aggiungere molti più dettagli e rispondere meglio alla domanda "perché Spark". Fondamentalmente, si tratta di scuoiare. Altre modifiche in arrivo, mentre scruto le differenze tra le mie app ... –
Uno dei migliori ripost in cui ho letto su Flex. Grazie – Thalaivar