[OO/Java] Model-View eventloop

[Verwijderd]

Wat OO guru-level response nodig voor het volgende probleem:

In het algemeen: 2 eventsources zijn elkaars listeners, een event in de ene source veroorzaakt een event in de ander en vica versa (ihb bijvoorbeeld een datamodel en een dataview daarop : de view genereert een DataViewItemChangedEvent oid, vervolgens wordt deze verandering doorgevoerd in het datamodel, die op zijn beurt weer een DataModelItemChanged event genereert om de view te updaten, maar deze update is dan dus redundant en veroorzaakt ook een DataViewItemChangedEvent, etc.)

wat oplossingen hiervoor:
events blocken tijdens update (niet echt handig wanneer er nog andere listeners zijn)
een redundante update blocken (view -> model -> view -> block)

Is hier nog een betere oplossing/pattern voor??

[Alarmnummer]

Ik denk dat het wel handig is als we een concreter voorbeeld nemen, bv de Combobox model en de JCombobox. Als de combobox model een event door stuurt naar de JCombobox, dan moet de JCombobox dit verwerken maar dan een event loze verandering doorvoeren. Hierdoor kom je niet in een lus terecht doordat de JCombobox weer aan de Combobox model loopt door te geven dat er iets is veranderd.

[Verwijderd]

OK, zo wordt het gedaan in swing, maar stel dat je wat eigen klasses hebt die in boven beschreven relatie tot elkaar staan, dan zal de klasse waar de event-loze verandering plaatsvindt zijn (eventuele) eigen listeners niet updaten ??

[Alarmnummer]

Je zou het ook kunnen doen door geen event door te sturen als er niets is veranderd (hierdoor pak je ook dit soort lussen er uiteindelijk uit). Ik controleer in ieder geval altijd dat er alleen een event verstuurd wordt, als er iets is veranderd.

[ Voor 27% gewijzigd door Alarmnummer op 02-02-2003 00:04 ]

[Verwijderd]

yep, dan is de lus niet langer dan een roundtrip.

[Verwijderd]

maar misschien had het beter gekund..

[Alarmnummer]

Als ik nog een keer jouw voorbeeld erbij pak. Als er dus een verandering is in eventsource 1, dan zal event source 2 daarvan op de hoogte gesteld moeten gaan worden. Event source2 die veranderd hierop en die zal op zijn buurt eventsource1 weer op de hoogte stellen.

Zie event source 1 als een werkende man.
Zie evnet source 2 als de vrouw van de werkende man.

-man gaat geld verdienen en stelt vrouw op de hoogte.
-vrouw gaat geld uitgeven en via de bank kom de man hiervan op de hoogte.
-de man gaat meer geld verdienen om de kosten te kunnen dekkken en stelt de vrouw hiervan op de hoogte.
-de vrouw gaat meer uitgeven omdat er meer geld is etc etc etc.

Zoals je ziet is dit op zich correct en zo`n 'lus' is dus goed omdat er niet echt sprake is van een lus, maar eerder van een spiraal.

Als je wel een lus zou hebben, dan zou je hem er goed uit kunnen pakken door te controleren of er ook een change is. Hierdoor kan je de lus doorbreken.

[Verwijderd]

Hehe, ok, maar dan is er bij elke slag nieuwe info (saldo van de dalende bankrekening) en is zo'n lus inderdaad gewenst.