[Xulfr] XBL et SVG.
Alexandre Poirot
poirot.alex at free.fr
Ven 5 Jan 16:12:18 CET 2007
Salut Paul,
Voilà un peu plus de 6 mois, j'ai répondu à un problème similaire (mais
plus simple!) sur les XBL;
j'ai décrit à l'époque les résultats de mes tests unitaires et ce qu'on
pouvait en déduire.
Mais depuis, j'ai passé 3 mois à modifier une appli(le fameux SEPT) pour
maîtriser tous les problèmes de chargement des XBL.
Mes conclusions sur le XBL sont :
- les hacks "hidden" sont quasi obligatoires
- le binding via les CSS est très obscur car on ne maîtrise rien du tout,
et vu que le comportement est très hasardeux, il est difficile (voir
impossible!) de comprendre et résoudre les bugs.
- c'est pourquoi je conseille d'utiliser la fonction document.addBinding;
Certes elle est encore plus hasardeuse, mais on maîtrise un peu plus ce
qu'il se passe.
Par exemple, on pourra décider et savoir quand les éléments fils du
content seront, à leur tour, bindés!
Voici l'ordre exact des appels à effectuer :
var e=document.createElement(...);
xxx.appendChild(e);
e.hidden=true;
document.addBinding(e,"/xxx/yyy/lesbindings.xml#lebinding");
function isBind() {
if (typeof(e.fonction_définie_dans_le_xbl)=="function") {
// l'élement est bel et bien "bindé" :
e.hidden=false;
} else {
window.setTimeout(isBind,100);
}
}
window.setTimeout(isBind,100);
Donc ce petit script marche dans 95% des cas avec du XUL.
Mais il s'avère que dans certains cas particuliers, cela ne marche qu'en
appelant le appendChild en dernier !?
(Si ça ne marche pas, n'hésites pas à changer l'ordre, désactiver le
hidden, etc. afin de trouver la bonne combinaison!)
Concernant le bug en variable globale, j'ai remarqué un problème proche
lorsqu'on travaille avec deux vues différentes via l'attribut
wrappedJSObject;
Impossible de créer des XBL SVG à partir d'une autre vue (rien ne
s'affiche alors que le binding est effectif)
alors que cela marche bien pour des XBL XUL ?!
On pourrait donc supposer qu'il y a des problèmes de contexte de
variables en SVG ...
Enfin, tu dis que cela se passe bien sur d'autres appli,
mais elles ne seraient pas sur un vieux xulrunner ?
Car l'appli sur laquelle j'ai bossé a rencontré pas mal de bugs entre ff
1.0 et ff 1.5,
à cause d'un comportement différent du moteur CSS et des XBL.
----
Alexandre
Un étudiant toujours motivé à la recherche d'un nouveau stage XUL, mais
aussi pour s'ouvrir l'esprit : Flex, XAML, ... ;)
Paul Rouget a écrit :
> Salut la liste.
>
> Désolé pour le contenu HTML, mais ça me permet de simplifier la mise
> en page.
>
> Je ne cherche pas obligatoirement les solutions à mes problèmes, mais
> des pistes,
> des conseils pour continuer à debuger tout ça. Si vous pouviez me dire
> ce que vous
> inspire tout ça, ça m'aiderait grandement:
>
> Bon... j'ai un soucis pour binder un élément créé dynamiquement.
> Voilà le contexte:
>
> Je suis dans le chrome.
> XulRunner 1.8.0.4
> J'ai une fenêtre XUL bourrée de XBL.
> Du SVG dans tous les sens.
>
> Voici mon DOM énormément simplifié, en rouge, le contenu anonyme:
>
> * * xul:audio*
> o svg:svg
> + ...
> + svg:zoomArea inherits svg:generic
> # svg:svg
> * *svg:Area* inherits svg:generic
> o svg:g
> + *svg:Section* inherits
> svg:generic
> # svg:rect
> # svg:g
> * *svg:Section*
> inherits svg:generic
> o svg:rect
> * *svg:Section*
> inherits svg:generic
> o svg:rect
>
>
> Et j'ai une jolie feuille de style qui me permet de styler tout ça, et
> aussi qui bind tout ces
> éléments (-moz-binding).
>
> J'ai un truc qui ressemble à ça dans mon css:
>
> section rect {
> fill: red;
> }
> section[checked="true"] rect {
> fill: green;
> }
>
>
> Ok, jusque là, tout va bien.
>
> Si, dynamiquement, dans mon code JS je modifie l'attribut checked
> d'une section pour qu'il passe à true, mon rect anonyme de devient pas
> vert. Par contre, si juste après je passe le ownerSVGElt (élément
> svg:svg pere du section) en visbility
> "hidden" puis "visible", mon rect devient bien vert. Je peux en conclure,
> peut être à tord que Gecko n'applique pas dans mon cas (parce qu'en
> général, ça fonctionne)
> le css après une modification dynamique du DOM svg.
>
> C'est mon premier soucis, mais à la limitte, ce workaround ne me dérange
> pas trop.
>
> Soucis suivant, là aussi ça va. Je crée dynamquement un élément svg:line.
> Il ne s'affiche pas mais est présent dans le DOM. Basculé le
> visibility ne change rien. Par contre, basculer
> le display (none/block) du ownerSvgElt me fait apparaitre mon line.
>
> Par contre, troisème problème, bien plus embètant:
> Accrochez vous:
> Je crée dynamiquement un élément section (createElementNS(svg ns)).
> je suis dans une fonction hors de mon XBL (une méthode d'un window XUL
> classic appelé quand j'appuie sur un bouton).
> Je fais donc mon createElementNS.
> Le résultat de mon createElementNS est affecté à une variable:
> var aSection = document.createElementNS("http://www.w3.org/2000/svg",
> "section");
> Le binding est effectué de manière asynchrone, mais, en gros, 6
> secondes après !!!
> Pourtant, ma machine est vraiment très puissante, cet élément section
> ne fait rien
> de vraiment extraordinaire, et, de plus, à la base, au chargement de
> l'appli, il existe
> 17 section, et ça ne lui pause aucun soucis (chargement de l'appli en
> 3 secondes, chargement
> de xulrunner inclu).
> Petit truc étrange:
> Si aSection est une variable globale (window.aSection) , le binding
> n'est *jamais* appliqué. Quel rapport me direz vous ?
> Je ne sais pas non plus! (je vous avais dit de vous accrocher).
> Mais continuons.
> Alors... quand je dis que le binding est appliqué, je veux dire que
> les fonctions apportées par ce binding
> sont présentes (après mon timeout de 6s, j'appelle une de celles ci,
> et elle fonctionne, c'est comme ça que
> je teste). Par contre, graphiquement, l'élément n'est pas présent.
> Pfiou...
> Donc, je teste mon super workaround. Idem, ne fonctionne pas en
> visibility, mais fonctionne avec display.
> Par contre, si je fais imédiatement un display none/block après le
> append, alors mon binding est appliqué
> de manière asynchrone, mais immédiatement (timeout de zero).
>
> Bon... comme vous l'avez vu, c'est le bordel, et tout cela vient d'un
> soucis de prise en compte du css
> par gecko dans le cas de modif du DOM dans un context SVG et XBL. J'ai
> déjà fait des applis bien complexes
> en SVG & XBL, sans avoir ce genre de soucis. Est-ce que celà vous
> cause ? Avez vous une piste ? N'importe
> quoi qui pourra m'aider à comprendre ce qu'il se passe.
>
> J'espère avoir été clair.
>
> Toute piste m'intéresse.
>
> Merci de m'avoir lu ^^
> --
> Paul Rouget
>
> http://www.xulfr.org - Technologies Mozilla
> http://blog.sexylizard.org
>
> _______________________________________________
> Xulfr mailing list
> Xulfr at lists.xulfr.org
> http://lists.xulfr.org/mailman/listinfo/xulfr
>
Plus d'informations sur la liste de diffusion Xulfr