Custom event.

[alphagon]

Salut! Am o problema dupa care m-am saturat sa mai gugalesc... Codul ar fi:

// LoginEvent.as

Cod: Selectaţi tot

package my.stupid.events
{
   [Event (name="loggedIn", type="flash.events.Event")]
   [Event (name="loggedOut", type="flash.events.Event")]
   import flash.events.Event;
   public class LoginEvent extends Event
   {
      public static const LOGGED_IN:String = "loggedIn";
      public static const LOGGED_OUT:String = "loggedOut";
      public function LoginEvent(type:String, bubbles:Boolean=true, cancelable:Boolean=false)
      {
         super(type, bubbles, cancelable);
      }
      
   }
}

// LoginWindow.mxml

Cod: Selectaţi tot

...
////!!!! *Nota: mai jos.
... somewhere, in a 'login' function:
   ... this.dispatchEvent(new LoginEvent(LoginEvent.LOGGED_IN)); // bubbles=true
...


// index.mxml

Cod: Selectaţi tot

<mx:Application ... initialize=""="init()">
...
   ////!!!! *Nota: am incercat optional si cu metadata, atat aici, cat si in LoginWindow.mxml
   <mx:Metadata>
      [Event (name="loggedIn", type="flash.events.Event")]
      [Event (name="loggedOut", type="flash.events.Event")]
   </mx:Metadata>

      public function init():void
      {
         loginWindow = new LoginWindow();
         this.addEventListener(LoginEvent.LOGGED_IN, onTest);
      }
      public function onTest(e:LoginEvent):void
      {
         trace("index got LoginEvent!"); // never gets it, of course
      }

...iar problema: LoginEvent-ul respectiv nu ajunge niciodata in index.mxml ... Astept cu nerabdare si deosebita apreciere orice sugestie, sfat sau injuratura. Multumesc!

PS: Ce vreau sa fac:
- componenta LoginWindow face o autentificare, la care, in functie de success/fail, as fi vrut sa transmita event-ul LOGGED_IN in sus catre root, aplicatia principala. Poate e un design defectuos...oricum astept sugestii sau orice

[Barna Biro]

Nu trebuie sa mai folosesti si tag-urile de Event in clasa respectiva care extende Event ( adica na, e cam senseless si relativ gresit daca e pana acolo ). Tot acolo, nu uita sa faci override la metoda clone(); fara care nu-ti vine evenimentul asa cum ar trebui sa vina. Fa override la clone si vezi atunci daca merge.

EDIT: Pardon, acuma am mai observat ceva. Pai tu ai atasat listener-u la obiectul gresit ( desi teoretic folosesti bubbling - DON'T !!! ). this.addEventListener(LoginEvent.LOGGED_IN, onTest); n-o sa mearga neam doarece "this" este aplicatia curenta, care nu face dispatch la niciun LoginEvent ( cel putin nu din cate vad eu - iar treaba cu bubbling-u, cum spuneam: not cool ).

Corect ar fi: loginWindow.addEventListener(LoginEvent.LOGGED_IN, onTest); iar in momentul in care acel LoginWindow dispatch-uie acel event de LOGGED_IN, atunci vei putea reactiona in aplicatia pricipala asa cum doresti ( in acea metoda onTest din cate vad ).

PS: Inca ceva, treaba cu bubbling nu e indicat. Don't really use it.

[alphagon]

Stai sa inteleg, ca daca am inteles bine, atunci e o gaura in conceptul lor, sau cel putin asa mi se pare mie, o poarcarie, dar daca nu... atunci gresesc eu (99%).
Eu credeam ca prin bubble, event-u se va transmite in sus catre root ca si o "bula" ;>> gen "mainApp (blâlâc)<- loginWindow (blâlâc)<- LoginEvent", la care ai spus:

"this" este aplicatia curenta, care nu face dispatch la niciun LoginEvent

. Pai bine, dar asta inseamna ca evenimentul este "valid" doar in "compartimentul" in care are loc. Sau nu?
Test: merge cu listener pe loginWindow. Bun. Asta a fost primul test. Acum sa incerc sa fac ce vroiam sa fac.


* nota: "blâlâc" - onomatopeea bulei ("bubbles").

[Barna Biro]

Sorry, am editat post-ul meu si am uitat sa corectez anumite lucruri. Cand am citit initial post-ul tau, am ignorat complet treaba cu bubbling ( si am cam "corcit" lucrurile uitand sa sterg anumite lucruri din reply-ul anterior ). Da, in esenta bubbling-u face ce ai spus. Sunt 3 faze in asa numitul "event flow", iar daca bubbling-u este "true" atunci in "bubbling phase" event-u parcurge obiectele din "chain", pornind de la obiectul care a dispatch-uit event-ul pana la ultimul parinte.

Exemplu simplu:

Cod: Selectaţi tot

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*"
   creationComplete="onCreationComplete()">
   
   <mx:Script>
      <![CDATA[
         import mx.controls.Alert;
         
         private function onCreationComplete():void
         {
            this.addEventListener("customEvent", onCustomEvent);
         }
         
         private function onCustomEvent(event:Event):void
         {
            Alert.show("Triggered!");
         }
         
      ]]>
   </mx:Script>
   
   <local:Comp
      width="400"
      height="200"/>
   
</mx:Application>

Iar in componenta "Comp" fac un simplu dispatch la un eveniment custom care ajunge intr-un final la parinte ( care este intr-adevar aplicatia principala - ca si in post-ul tau initial ):

Cod: Selectaţi tot

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300">
   
   <mx:Script>
      <![CDATA[
         
         private function doClick():void
         {
            var event:Event = new Event("customEvent", true, false);
            this.dispatchEvent(event);
         }
         
      ]]>
   </mx:Script>
   
   <mx:Button label="Push" click="doClick()"/>
   
</mx:Canvas>

Nu toate evenimentele au acest bubbling phase si nici nu e prea eficient, cu atat mai putin usor de urmarit. "On the long run" poate provoca mai multe probleme decat solutii... doar gandeste sa ai listenere multiple in diferite componente care cumva se afla in acelasi chain si care asculta la un anumit event ( de ex: "doSomething" ) dar acel eveniment sa fie de fapt diferit la fiecare ( si sa fie chiar dispatch-uit de componente diferite, cu scopuri diferite si etc ). Iti dai seama ce se intampla cand tu faci un dispatch la un astfel de eveniment bubble-uit si iti raspund N componente desi tu de fapt vroiai sa comunici doar cu o singura componenta...

Ar fi ideal daca ai evita bubbling-u ( exceptie situatiile in care chiar e nevoie de asa ceva ).

Sorry again pentru reply-ul anterior ( destul de confuz ) Cred ca ar fi cazul sa bag somn.

[alphagon]

A mers dom'le animalu'. Am lasat event-ul cu bubble, cel putin cand vine vorba de LoginEvent, deoarece deocamdata nu`mi pot imagina situatie in care m`ar incomoda metoda asta. Dar mai e timp sa dau si de ele;>


// index.mxml:

Cod: Selectaţi tot

      public function init():void
      {
         loginWindow = new LoginWindow();
         this.addEventListener(LoginEvent.LOGGED_IN, onTest); // chiar si pe componenta principala...
      }

Si da, ai avut dreptate, erau inutile blocurile metadata, am scapat de ele. Dar na, asa citisem in help ;>>
Dupa ora 12 nici eu nu mai dau acelasi randament, e de inteles ;> Mersi om.

PS: azi merge, dar daca e sa ma uit pe cod... parca e la fel ca si ieri cand nu mergea. Nu am modificat mare lucru...ciudat. ;.> in fine..next!

[Barna Biro]

Na, cum crezi tu Eu in locul tau tot as evita bubbling-u mai ales ca, chiar e lipsit de sens in acest caz. Mai bine pui bubbling-u pe "false" si atasezi listener-u componentei direct ( ca si in primul meu reply ) fara sa risti sa te incurci mai tarziu in acel listener sau fara sa mai ai habar oare de unde vine dispatch-uit acel event ( + si cateva chestii legate de performanta ). Dar na, e alegerea ta... Have fun.

[alphagon]

Mi-ai putea da un exemplu ceva mai concret unde bubble-ul ar putea crea probleme? Un scenariu..

[Barna Biro]

Mi-ai putea da un exemplu ceva mai concret unde bubble-ul ar putea crea probleme? Un scenariu..

Acuma, sper ca nu m-am exprimat tare prost. Si bubbling-u are rolul lui, si in anumite situatii e folosit si e "relativ ok" ( ca si cand vine vorba de scrollbar-uri si diferite butoane care pot avea listenerele cine stie unde pentru a putea fi "monitorizate global" si de a putea reactiona la un astfel de eveniment "global" ).

Pana la urma, nu pot spune ca bubbling-u e "extremely bad" ci doar ca deschide mai multe portite catre posibile erori/probleme viitoare. Un scenariu mai concret: sa spunem ca iti creezi aplicatia pe mai multe module ( din .swf-uri separate ) unde fiecare modul dispatch-uie cine stie ce evenimente bubble-uite pentru a semnala o schimbare in stare si la care sa poti sa reactionezi in "main".

Gandeste ce s-ar intampla atunci cand ai incepe sa stack-uie module ( adica sa compui de exemplu o componenta mai mare din 2-3 sau mai multe componente micutze - si poate si acele componente la randul lor sa fie compuse din alte componente care fac dispatch la evenimente bubble-uite ) iar intr-un astfel de modul te-ai inscrie la un event al carui nume a fost deja folosit intr-un alt modul si care face si bubbling ( evident, tu poate nu stii ca acel nume e deja folosit - si scopul folosirii poate chiar e complet diferit )... In modulul nou, tu poate nu ai nicio treaba cu celalalt modul, ci pur si simplu ai ceva ce vrei sa se schimbe atunci cand tot in interiorul aceluiasi modul se intampla ceva. Aici intervine problema... Daca in celalalt modul faci ceva schimbare care va trimite un eveniment bubbel-uit care se regaseste si intr-un alt modul, adica exista un listener care asteapta un eveniment de acelasi tip ( listener-ul respectiv avand scopuri total diferite ) atunci mai mult ca sigur ca o sa te trezesti cu o tona de erori, o aplicatie data complet peste cap si nici macar nu o sa ai de unde sa aflii de ce ( debugger-u n-o sa te ajute in astfel de situatii ).

Asta ar fi situatia "fericita", gandeste ca acelasi lucru s-ar putea intampla daca te pune cineva sa lucrezi pe proiectul unui al developer care a folosit bubbling si diferite swf-uri pentru a face who knows what ( sau nici nu are nevoie de swf-uri, ci pur si simplu sa fi construit aplicatia in asa fel incat cine stie de unde sa bubble-uie un event si sa-l prinda iara who knows where )... daca ai cumva "norocul" sa definesti cumva si tu un eveniment cu acelasi nume ca si cel folosit de developer-ul anterior ( despre care tu nu prea ai de unde sa stii prea multe - si mai ales nu informatii de genu ), atunci sa vezi cum te trezesti cu N erori de cine stie unde si mai ales de ce, cand tu nu ai facut altceva decat incercai sa testezi noua ta implementare ( care sintactic e extrem de corect dar tot o ia razna dintr-un "motiv necunoscut"... si atunci stai ore, zile, si mai multe zile pana intr-un final iti dai seama care-i problema si sa ajungi la concluzia: "sa-l bata D******* pe ala cu bubbling-u lui cu tot" )...

Nu stiu daca am fost suficient de clar, dar sper ca ai inteles ideea. Deci bubbling-u nu e "extremly bad" dar nici bun nu e, si in parerea mea ar trebui evitat ( exceptie situatiile in care chiar nu ai de ales - dar nu imi prea vin multe situatii de genu in minte, doar aia cu scrolling-u si poate inca 1-2 - dar nici acolo nu e chiar obligatoriu sa folosesti bubbling daca scrollbar-u tau nu trebuie "monitorizat" din orice punct al aplicatiei - si chiar si daca ar trebui monitorizat, sunt convins ca ar gasi omul solutii mult mai bune decat bubbling-u daca ar cauta ). Pe scurt: Try avoiding ambiguous and spaghetti code!

[alphagon]

Aham... s-a mai conturat si-n capu' meu ideea. Mersi mult & e de apreciat ca iti dedici timpul unui serviciu moca cu atata pasiune. Cel putin mie mi-ai raspuns tot timpul prompt si nu oricum, ci cu ..interes. Suna poate gay ;>> (pasiune, alea alea) dar de persoane de tipul asta dau foarte rar. Si nu's gay. ;p
Respect

[Barna Biro]

Mercy. Unii se pricep la rezumate mult mai bine ( mie imi place sa ma bag in prea multe explicatii si parca uneori incerc sa acopar prea mult teren cu un singur reply ) si m-am gandit sa postez un astfel de rezumat ca si "my last reply to this thread":

Bubbling is effectively the same as having a loud conversation on your cellphone in public. Might save you the time and hassle of finding a private room, but someday something you say will end up being overheard by the wrong person.

Numai bine si multa bafta in continuare.