Zewnętrzny plik AS

Cześć

piszę sobie aplikacje w Adobe Flex 3.0 + Action Script. Na podanym przykładzie (interesuje mnie tylko część AS) :

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:Script>
        <![CDATA[
            import mx.rpc.events.ResultEvent;
            import mx.rpc.events.FaultEvent;
            import mx.controls.Alert;

            private var alert:Alert;

            private function loadGallery(src:String):void {
                httpService.url = src;
                httpService.send();
            }

            private function httpService_fault(evt:FaultEvent):void {
                var title:String = evt.type + " (" + evt.fault.faultCode + ")";
                var text:String = evt.fault.faultString;
                alert = Alert.show(text, title);
                xmlListColl.removeAll();
            }

            private function httpService_result(evt:ResultEvent):void {
                var xmlList:XMLList = XML(evt.result).images.image;
                xmlListColl = new XMLListCollection(xmlList);
            }
        ]]>
    </mx:Script>

    .........
    ........

chciałbym go umieścić w osobnym pliku *.as jak to zrobić i jak wskazać w projekcie ten skrypt z zewnątrz ?

RTFM! jedyny parametr przyjmowany przez Script to source i to właśnie jest to, czego potrzebujesz.

btw skrót od actionscript to AS, a nie A.S.
jeśli korzystasz z lokalnych obiektów do łączenia się z webserwisami, to pamiętaj o posprzątaniu po sobie - albo wywołuj metody ws z ostatnim parametrem (bodajże useWeakReference) true, albo zdejmuj listenery, i to zarówno w przypadku sukcesu, jak i błędu. inaczej w pamięci zostają śmieci - utworzone obiekty zawierają w sobie referencję do metod-listenerów, które zwykle żyją znacznie dłużej niż obiekty webserwisów i tym samym powodują wyciek pamięci.
pamiętaj, to że środowisko zawiera garbage collector nie usprawiedliwia śmiecenia.

dzięki ! nawet za dodatkowe info, jak : useWeakReference

Nasuwa mi się takie pytanie dot. argumentu useWeakReference. Jeśli pozostawimy domyślnie czy na false, jak to w praktyce wygląda. Czy serwer będzie dłużej mielił jakieś dane, czy komp się zawiesi, nie wiem... ?

masz to opisane w helpie, chyba łatwiej jest wcisnąć F1 niż zadać pytanie na forum... poczytaj np. http://gingerbinger.com/2010/07/actionscript-3-0-events-the-myth-of-useweakreference/. a po naszemu: GC usuwa co jakiś czas z pamięci obiekty, które nie odwołują się do istniejących poza nimi obiektów i do których nie odwołują się inne obiekty, tzn. nie mają referencji. jeśli obiekt trzyma w sobie referencję do jakiejś statycznej zmiennej, to nie będzie nigdy zwolniony, a jeśli trzyma referencję do zmiennej niestatycznej, to będzie żył co najmniej tak długo, jak ta zmienna. jeśli jednak referencja będzie typu weak, to GC nie będzie brał jej pod uwagę przy sprawdzaniu, czy posiadacz tej referencji może zostać usunięty z pamięci.
tutaj powoduje to, że nie musisz pamiętać o odczepieniu każdego listenera, jednak może też spowodować efekt uboczny w postaci zwolnienia obiektu zanim jeszcze dane zostaną dociągnięte i zostanie wywołany EventListener. jeśli więc nie łapiesz do końca, jak działa ten mechanizm, to użyj innego - dla każdego addEventListener (i pokrewnych metod) MUSI być zawsze wywołany removeEventListener i to niezależnie od tego, czy ściągnięcie danych się udało czy nie. jest jeszcze jedna alternatywa - dla każdego webserwisu robisz jeden obiekt obsługujący go w ramach danej klasy/pliku as i raz tylko podłączasz do niego listener na dany event, przy czym każdy listener może być zdefiniowany tylko w tej klasie, w której istnieje obiekt opakowujący webserwis; w efekcie kiedy przestajesz używać głównej klasy (np. zamykasz okno modalne) to GC będzie mógł posprzątać całość.

poniższy kod jest napisany brzydko i z palca, chodzi tylko o zaprezentowanie idei, nie wyciągaj z tego wniosków na temat tego jak formatować kod.
pierwszy sposób (weak reference):

var ws = new WS()
function OnClick(e) { ws.addEventListener(E.A, onA, false, 0, true); ws.addEventListener(E.Fail, ws.onFail, false, 0, true); ws.getA(); }

function onA(e) { ... }
function onFail(e) { ... }

pierwszy sposób w wersji mogącej spowodować niewykonanie handlera:

function OnClick(e) { 
    var ws = new WS(); ws.addEventListener(E.A, onA, false, 0, true); ws.addEventListener(E.Fail, ws.onFail, false, 0, true); 
    ws.getA(); 
} // po wyjściu z tej metody obiekt ws może być od razu sprzątnięty z pamięci i onA ani onFail nigdy się nie wykonają

function onA(e) { ... }
function onFail(e) { ... }

drugi, moim zdaniem najlepszy sposób - zawsze sprzątać po sobie:

function OnClick(e) { 
    var ws = new WS(); ws.addEventListener(E.A, onA); ws.addEventListener(E.Fail, ws.onFail); 
    ws.getA(); 
}

function onA(e) { e.target.removeEventListener(onA); e.target.removeEventListener(onFail); ... }
function onFail(e) { e.target.removeEventListener(onA); e.target.removeEventListener(onFail); ... }

trzeci, brzydki, ale najłatwiejszy sposób:

var ws; 
function init() { 
    ws = new WS(); 
    ws.addEventListener(E.A, onA); ws.addEventListener(E.Fail, ws.onFail); // listenery przyczepiane RAZ na czas życia obiektu this
} 

function OnClick(e) { ws.getA(); }

function onA(e) { ... }
function onFail(e) { ... }
// listenery zginą razem z obiektem this, a wtedy będzie mógł zginąć obiekt ws też powiązany tylko z obiektem this

pamiętaj, że masz kilka eventów sygnalizujących błędy.