Idee Bestätigungspflichtiger Event

[K-Grabowski]

Hab da ne ganz coole Idee für nen Event:

Anwendungsfall:
der nächste Inhalt für ne Website soll geladen werden. Allerdings soll bevor geladen werden soll, erstmal der Preloader eingefadet werden. Also schmeißt die Klasse die fürs laden verantwortlich ist einen Event und gibt dem Event eine Callback-Funktin mit. Die GUI empfängt den Event, fadet den Preloader ein, und bestätigt danach den Event, worauf dieser die Callback Function aufruft, jetzt beginnt der Loader mit dem Laden.

Was haltet ihr davon, durch diesen Event ist gewährleistet das die GUI den Loader nicht kennen muss.

Hättet ihr ne Idee wie man diesen Event nennen könnte?

Im Prinzip ist es ja ein Bestätigungspflichtiger Event, aber mir fällt kein Name ein.

[K-Grabowski]

Ich hab das ganze mal PendingEvent genannt. Also schwebender Event, ich denke das trifft die Sache ganz gut, oder?

[Janoscharlipp]

hmm, was wäre, wenn sich mehrere Listener für das Event anmelden? Wird dann das Callback mehrmals gerufen?

[K-Grabowski]

Gute Frage.

Ich werfe derzeit eine Exception sobald die die proceed methode des Events ein zweites mal aufgerufen wird.

Allerdings würde bei mir der Fall im konkreten Beispiel nicht auftreten.

[p-flash]

Die Idee hört sich eigentlich ganz nett an, aber mir fällt keine Situation ein, in der deine Variante wirklich viel besser wäre. Dadurch, dass sich gui und preloader über das event kommunizieren ist das spätere ändern auf jeden fall einfacher.

p-flash

[K-Grabowski]

Naja, falls man eine etwas tiefere Hierarchie von Objekten hat, und der Aufwand die Events oder das Objekt hindurchzureichen zu hoch ist.

Ich habe z.b. eine Game-Instance, welche ein Level lädt und diese über einen Levelloader realisiert. Dieser Levelloader wiederum schmeißt ein Event über einen FrontController, bei dem man sich anmelden kann um Events zu empfangen.

[hazy fantazy]

Zitat von K-Grabowski

Gute Frage.

Ich werfe derzeit eine Exception sobald die die proceed methode des Events ein zweites mal aufgerufen wird.

Allerdings würde bei mir der Fall im konkreten Beispiel nicht auftreten.

Eine andere Möglichkeit wäre es, das target oder gleich ein ganz neues Event als Parameter an proceed zu übergeben.

mfg. h

[Omega Psi]

Was ist, wenn das Event aber nicht bestätigt wird? Hängt dann der Laden?

Ich bin mir auch nicht so ganz sicher, ob ich den Nutzen wirklich erkenne.

Naja, falls man eine etwas tiefere Hierarchie von Objekten hat, und der Aufwand die Events oder das Objekt hindurchzureichen zu hoch ist.

Events muss man doch nicht durchreichen... wenn ein Event gefeuert wird, muss es doch nur gehört werden... er ist doch global verfügbar, oder hab ich da was falsch in erinnerung?