Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Flash Builder 4 – Refactoring (déplacement, renommage de classes / propriétés)

Les propriétaires de Flex Builder 3 connaissent les 2 problèmes qu'il a au niveau du refactoring:

• La mise à jour de référence est très longue (4-5 minutes la première fois)
• Après avoir attendu, le refactoring ne fonctionne pas (encore moins quand on déplace une classe de package)

Bref, très frustrant quand on doit tout faire à la main, surtout quand les temps de compilation sont longs.

Et bien vous serez sûrement heureux d'apprendre que la fonctionnalité de refactoring fonctionne à merveille dans Flash Builder 4!

Refactoring classique

Par refactoring classique, j'entends un simple renommage de propriété ou de classe. Dans Flex Builder 3, il y avait une option facultative au moment du refactoring qui était "Update references". Celle-ci devait en théorie faire les changements aussi aux endroits où la classe / propriétés étaient utilisées.

Dans la pratique, cela lançait une "indexation" de classes qui passait sur toutes vos classes/librairies mais aussi sur celles du Framework Flex. Cette opération n'était réalisé qu'une seule fois (par démarrage de Flex Builder) et prenait 4-5 minutes pour un projet conséquent et pouvait crasher la JVM si vous étiez un peu à la limite de RAM. Le plus souvent, cela ne fonctionnait au final pas du tout. Le nom de la classe changeait mais pas son package et les définitions d'import  dans les autres classes. Bref, inutilisable.

Après avoir bidouillé le refactoring Flash Builder 4 dans tous les sens, je suis vraiment content du résultat, il fonctionne enfin correctement, comme il le devrait. Les packages sont mis à jour, les définitions d'import sont aussi impactés. On peut enfin faire du Drag N Drop dans la nouvelle vue "Package Explorer" sans prendre peur.

Et l'étape d'indexation n'est plus, tout se fait de manière immédiate, un vrai régal.

Refactoring dans les librairies

Dans Flex Builder 3, j'ai souvent eu à utiliser des projets de type Flex Library. Très pratique quand on veut partager du code entre plusieurs projets par exemple. Le problème est que si vous deviez faire du refactoring dans une classe des librairies (move, changement de package), tout d"abord, les modifications sur les autres classes n'étaient pas impactées (voir au dessus), mais en plus, cette classe devenait non-incluse dans la librairie.

En effet, si on allait dans les propriétés du projet > Flex Build Path > Classes, la classe modifiée était décochée. Donc vos projets dépendant de cette librairie ne retrouvait plus la définition de la classe et il fallait aller la recocher à la main. Et le fait de recocher cette classe à la main, faisait comme si vous aviez fait un Clean + Build et vous perdiez donc votre compilation incrémentale. Bref, une perte de temps énorme sur le développement à regarder "Building workspace…" en bas à droite.

Dans Flash Builder 4, non seulement le refactoring dans les librairies fonctionne, mais en plus, il impacte bien les changements dans les projets qui utilisent la librairie. Et, nouvelle option dans Flash Builder 4, vous pouvez décider de ne pas cocher les classes que vous voulez utiliser d'une Flex Library mais simplement indiquer que vous voulez embarquer toutes les classes dans la librairie. Dans le cas d'une librairie Merged In, Flex fera le distingo entre les classes utilisées ou non à la compilation.

Pour ceux qui utilisent un système de versionning type SVN, plus de conflits donc sur le fichier .actionScriptProperties

: