Nie mogę nic powiedzieć o migracji komponentów innych firm. Nie używam tych, o których wspomniałeś.
Mogę wam jednak powiedzieć, że nie będziecie w stanie po prostu załadować istniejącego projektu do Flash Builder 4, zmienić zestawu SDK na 4.0 i oczekiwać, że przekompiluje. Ogromna liczba rzeczy zmieniła się w programie Flex 4, często w sposób niekompletny.
Masz teraz dwie równoległe bibliotek komponentów, iskra i MX. MX jest starą biblioteką komponentów Flex 3, czasami nazywaną Halo, choć to technicznie tylko nazwa domyślnej skóry. Spark to nowa biblioteka komponentów Flex 4, która tylko częściowo zastępuje MX.
Działają one we współdziałaniu. Możesz używać obu w jednej aplikacji i możesz np. Umieszczać komponenty Sparka w kontenerach MX, takich jak ViewStack. Istnieją również naturalne podziały w aplikacji, w których możliwe jest posiadanie jednej strony przy użyciu Sparka, drugiego MX, bez martwienia się o kłopoty, ponieważ nie współdziałają na poziomie GUI. Na przykład takie okna dialogowe.
Powodem, dla którego zrobili to wszystko, było wspieranie nowych rzeczy, o których słyszeliście: Flash Catalyst, FXG i tak dalej. Jeśli używasz zapasowej skórki Halo, nie widzę, aby Spark był dla ciebie ważny, poza tym, że jest to Przyszłość.
(Na marginesie: Jaka jest składnia Markdown uzyskać Kreator-of-Oz dudniącym efekt echa?)
Joan Lafferty (Flex SDK Jakość Lead) posiada cenny artykuł, Differences between Flex 3 and Flex 4. Na page 4 ma tabelę zawierającą składniki Flex 3 MX, które nie zostały zastąpione przez komponenty Spark w środowisku Flex 4. Większość z nich nie ma własnego wyglądu, na przykład Accordion, więc nie trzeba ich karać, lub takie rzeczy jak okna dialogowe, takie jak Alert. (Powinieneś przeczytać całą resztę tego artykułu, która obejmuje rzeczy, których ja nie mam, ponieważ nie spotkałem się jeszcze z żadnymi różnicami.)
Mówiąc o skórkach, tylko dwie ze skórek MX od Flex 3 są nadal obsługiwane w wersji Flex 4. Bardziej kolorowe skórki MX zniknęły, chociaż istnieje nowy zestaw kolorowych skórek opartych na Spark, które pokazują niektóre z rzeczy, które możesz zrobić z FXG i innymi. Jeśli naprawdę podobał Ci się jeden z usuniętych, możesz bez wątpienia odtworzyć je na Sparku, ale nie jest on dostępny po wyjęciu z pudełka.
Wiele rzeczy zostało renamed, a niektóre zamienniki Iskara dla komponentów MX mają różne interfejsy, a więc mają different names. Na przykład, aby przenieść się całkowicie do Sparka, musisz zmienić swoje VBox es na VGroup s. Jest wiele irytujących drobnych różnic.
Ponieważ całego podwójnego librarything GUI, Adobe znalazły się z grupą znaczników MXML jak <Script> i <Style> które nie są właściwie częścią MX, które działają równie dobrze dla Spark. Zamiast zduplikowanego zestawu tagów przenieśli je do nowej przestrzeni nazw XML. Jest to problem dla osób wykonujących częściową migrację istniejących aplikacji opartych na MX, ponieważ oznacza to, że nadal używasz aliasu mx dla biblioteki komponentów MX, więc tagi wspólne dla obu bibliotek muszą zostać zmienione. Nowa domyślna przestrzeń nazw XML dla tych znaczników to fx, dlatego każda nazwa <mx:Script> musi zostać zmieniona na <fx:Script> itd. IDE nie robi tego za ciebie przy imporcie projektu. Po prostu znajdujesz je jeden po drugim, próbując stworzyć zaimportowany projekt.
Jeśli planujesz przenieść się całkowicie do Sparka, możesz uniknąć bólu tutaj. Zamiast akceptować domyślny alias obszaru nazw w tagach innych niż MX, możesz pozwolić mu dalej używać mx, ponieważ nie będziesz tego potrzebować dla MX, a Spark domyślnie używa s.
Twoim pierwszym zadaniem po zainstalowaniu Flash Builder 4 powinno być wygenerowanie świeżego nowego projektu, abyś mógł go studiować i kopiować i wklejać takie rzeczy jak te deklaracje przestrzeni nazw z niego.
Innym opadem całego MX vs. Spark i bałaganu w przestrzeni nazw jest to, że twój CSS może wymagać ulepszenia. Flex ma niestandardowe rozszerzenie CSS dla tego, który wygląda tak:
@namespace mx "library://ns.adobe.com/flex/mx";
mx|Application {
....
wszystkie adresy URL przestrzeni nazw zmieniły zarówno między Flex 3 i Flex 4, oraz w co najmniej jednym przypadku zmienił ponownie podczas procesu beta Flex 4.
http://www.adobe.com/2006/mxml jest teraz http://ns.adobe.com/mxml/2009 library://ns.adobe.com/flex/halo jest teraz library://ns.adobe.com/flex/mx
local() forma określania osadzonych nazwy czcionek przez ich wspólną nazwą w CSS nie działa dłużej. Musisz użyć formularza url() i podać ścieżkę do pliku czcionki.
Pułapką, na którą należy zwrócić uwagę, jest to, że oznacza to, że jeśli osadzasz wiele wariantów pojedynczej czcionki (np. Normalne i pogrubione), twój poprzedni kod odnosi się do tej samej nazwy czcionki, ale twój nowy wskaże dwa różne pliki, ponieważ te dwa wagi nie znajdują się w tym samym pliku .ttf lub .otf. Na przykład w ten sposób:
@font-face {
src: local("Verdana");
fontFamily: VerdanaEmbedded;
fontWeight: normal;
}
@font-face {
src: local("Verdana");
fontFamily: VerdanaEmbedded;
fontWeight: bold;
}
musi być zmieniony na to:
@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;
}
W Flex 3, kompilator domyślić, które pliki dwie czcionki .ttf powyższy kod odnosi się na podstawie atrybutu fontWeight. W wersji Flex 4 kompilator sprawia, że wyraźnie to przekazujesz.
Jeśli osadzasz czcionki w aplikacji i nadal używasz kontrolek MX, tekst prawdopodobnie zniknie lub przywróci domyślną czcionkę. Dzieje się tak dlatego, że domyślnie Flex 4 wykorzystuje inny mechanizm osadzania czcionek pod maską, aby wesprzeć ulepszony mechanizm renderowania czcionek w programie Flash Player 10. Aby osadzić czcionkę w starszym trybie, tak aby stare kontrolki MX nadal mogły z niej korzystać, ustawić atrybut CSS embedAsCFF na false.
Mechanizm państw jest zupełnie inny. Ten kod Flex 3:
<mx:State name="alternate">
<mx:SetProperty target="{myField}" name="editable" value="false"/>
</mx:State>
....
<mx:Form ...>
<mx:TextInput id="myField"/>
....
</mx:Form>
staje się to w Flex 4:
<mx:State name="alternate"/>
....
<mx:Form ...>
<mx:TextInput id="myField" editable.alternate="false"/>
....
</mx:Form>
Nowa droga ma większy sens dla mnie, ponieważ umieszcza wszystkie poszczególne stany elementów w samej zmiennej składowej, zamiast na górze pliku MXML w pełnym rozmiarze bloku <mx:State>, ale przeniesienie do nowego mechanizmu jest nieco męczące. Konwersja nie jest zautomatyzowana przez IDE, choć tak naprawdę może być.
Istnieje kilka tagów, które nie są już dozwolone jako bezpośrednie elementy podrzędne tagu <Application>. Dzielą się one na kilka kategorii: walidatorami, efektów itp Teraz trzeba zapakować je w górę do nowego <fx:Declarations> znacznika tak:
<fx:Declarations>
<mx:Dissolve id="myTransition" duration="100" target="{this}"/>
</fx:Declarations>
Jest nowa opcja projekt w programie Flash Builder, który pozwala kontynuować używając Zestaw SDK Flex 3.5 sam, bez Spark, dla łatwiejszej migracji. To jest dobre dla początkowych testów, ale w pewnym momencie chcesz iść do przodu, w którym momencie musisz walczyć ze wszystkimi powyższymi.
Nowy kompilator również nie wydaje mi się o wiele szybszy. Nie porównałem tego, po prostu czuję, co jest dla mnie ważne, ponieważ nadal sprawia mi wrażenie, że uderzam głową o biurko. :) Na pewno nie używa pozostałych 7 rdzeni w moim boxie rozwojowym. Grrr.
Czy iskra warta wszystkich tych problemów, aby się do niej zbliżyć? – Amarghosh
Edytowałem powyższe, aby dodać dużo więcej szczegółów i lepiej odpowiedzieć na pytanie "dlaczego Spark". Zasadniczo sprowadza się do skórowania. Więcej zmian po drodze, jak przeglądam różnice dla mojej aplikacji ... –
Jedna z najlepszych ripost, które czytałem na Flex. Dzięki – Thalaivar