Je ne pense pas que tu puisse avec Fyne generer un cycle, car l'ui ne va generer un changement dans le data binding que si celui-ci est le resultat d'une action de l'utilisateur. Donc un changement dans le data binding, va faire une mise a jour de l'ui, mais l'ui ne va pas generer de mise a jour du data binding apres ce changement.
Par contre, effectivement, il y a des possibilites de change after view (si j'en comprend bien ce que tu decris), si il y a une entree utilisateur sur l'ui au meme moment que le data binding decide de faire un changement. Mais dans ce scenario, le data binding propagera tout de meme l'entree utilisateur ce qui laisse la possibilite au data binding de resoudre le conflit. Du coup, dans le cas d'un protocol reseau, on s'attenderait a ce que cela soit gerer dans le backend.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
Je ne pense pas que tu puisse avec Fyne generer un cycle, car l'ui ne va generer un changement dans le data binding que si celui-ci est le resultat d'une action de l'utilisateur. Donc un changement dans le data binding, va faire une mise a jour de l'ui, mais l'ui ne va pas generer de mise a jour du data binding apres ce changement.
Par contre, effectivement, il y a des possibilites de change after view (si j'en comprend bien ce que tu decris), si il y a une entree utilisateur sur l'ui au meme moment que le data binding decide de faire un changement. Mais dans ce scenario, le data binding propagera tout de meme l'entree utilisateur ce qui laisse la possibilite au data binding de resoudre le conflit. Du coup, dans le cas d'un protocol reseau, on s'attenderait a ce que cela soit gerer dans le backend.