octobre
2011
Un article de bouye
#Michael Heinrichs
Le binding sera étendu et complété dans les versions futures
Extension du modèle des beans + ajout de l’accesseur à l’objet propriété.
Utiliser l’objet primitif plutôt que l’objet Generics pour de meilleures performances.
Support des propriétés Read-only (pas de setter et pas de binding).
Lazy evaluation
Le calcul du résultat n’a lieu que lorsqu’il y a un acces.
Change event -> envoie à chaque changement
Invalidation event -> envoie uniquement lors de la première invalidation.
Si un change listener est attaché, la valeur est recalculée à chaque fois. lazy evaluation-> eager evaluation.
Le binding fonctionne un peu comme une formule dans une feuille de calcul Excel.
Une propriété ne peut plus être settée tant qu’elle n’est pas unbindée.
Le binding bidirectionnel permet de setter l’une ou l’autre des extrémités.
Depuis le beans on peut soit attacher un InvalidationListener ou surcharger la méthode invalidated() de la propriété. La surcharge est plus rapide (pas d’Event généré).
Une propriété peut lancer un change event en appelant fireValueChangegEvent()
On transforme une propriété en Read-only en faisant référence à leur type parent Read-only et en supprimant le setter.
High level API
Permet de définir des Bindings de manière intuitive et naturelle en chainant des méthodes entre elles.
Ex: a.add(b).multiply(c) -> (a+b)*c
On peut aussi utiliser la classe Bindings qui a des méthodes statiques.
Il n’y a aucune différence à utiliser l’un ou l’autre.
concat() = concaténation de chaines
format() = formattage de chaines.
asString() = crée une StringProperty liée à la NumberProperty source.
select() = appelle le getter ex : a.bProperty().select(« c », « d ») = a.getB().getC().getD()
select(), then(), otherwise() = a ? b : c
Low level API
Permet de créer des nouveaux Bindings
Surcharger computeValue()pour faire le calcul.
entends binding class
bind dependencies
implement computeValue()
Prêt à etre utilisée dans l’API de haut niveau.
La plupart du temps les implémentations utilisent des références fortes. Il est cependant possible d’utiliser des weak références.
Il est parfois nécessaire de faire un mécanisme d’invalidation plus complexe. -> isValid(), onInvalidating(), invalidate()
Méthodes optionnelles :
getDependencies() principalement utilisées pour le déboggage. Pas utilisée lors d’une exécution normale
dispose() nettoyage pour un futur portage vers des plateformes où la gestion de la mémoire est importante.
Taille mémoire plus importante lorsqu’on utilise l’API de haut niveau. Il y a plus d’événements aussi.
En général mieux vaut utiliser l’API de haut niveau et n’utiliser celle de bas niveau que lorsqu’on a des problèmes de performance.
Besoin de retour des utilisateurs pour savoir quoi améliorer dans les versions futures.
2 Commentaires + Ajouter un commentaire
Commentaires récents
- dans Back from the future…
- dans Back from the future…
- dans Static linking = does not Compute
- dans Paquetage x 2
- dans Why you little…
Malheureusement non car la présentation n’a durée qu’une heure et donc Michael Heinrichs a du faire au plus court possible. Pareil, sur l’instant on a pas trop le temps de noter les détails sous peine de rater d’autres choses. A voir si c’est plus clair via la présentation sur Parleys.
Ce lien (http://www.devoxx.com/pages/viewpage.action?pageId=5014845) est pour la présentation de la Devoxx qui est donc plus récente. Peut-être a-t-il donné plus de détails à ce sujet.
Pour le surcharge de Invalidate() ça devient un peu vague pour moi ,pouvez vous donnez un exemple de surcharge?