« La structure de toute “chose”, qu'il s'agisse d'un langage, d'une maison, d'une machine etc., se résume à des relations. » — Alfred Korzybski
Vous n'êtes pas logué. Veuillez vous loguer ou vous enregistrer.
Hoa Forum » Actualités » Hoa_Xyl vient d'apparaître dans le tronc
Pages Précédent 1 2 3 4 5 6 7 8 9 Suivant
Vous devez vous loguer ou vous enregistrer pour poster une réponse
pas encore testé je peux pas te dire tout de suite
voila si sa correspond plus à un import ou un use ...
je testes demain !!
Juste pour répondre à
Pour le format WebM, VLC, Miro, Firefox, Chrome etc., savent tous le lire. Tu peux donc utiliser VLC ou Firefox .
et éventuellement à
Lu aujourd'hui : « Comment on lit une vidéo WebM ? Il faut installer un plugin ? » /me va se prendre et revient.
Sous ubuntu à jour, aucuns navigateurs récents firefox/firefox-beta/chrome, ni vlc ne sont capables de lire le format .webm
Donc bon c'est chouette de courir après les nouveaux standards, mais il faut que ses utilisateurs puissent suivre aussi 
Je sais pas si je ferais l'effort de redémarrer mon ordinateur pour booter sur windows à chaque nouvelle vidéo 
Voilà c'était mon petit coup de gueule gentillet
Hey ,
VLC lit le format WebM depuis sa vesion 1.1.0. Miro le lit aussi. Chrome 6 (dev channel), Firefox 4, Opera 10.6 également. Bon d'accord, c'est encore une early technology mais il faut l'adopter massivement pour le bien du Web .
Donc si, VLC le lit. Et cette version est sortie depuis un moment non ?
Pour plus d'informations : http://webmproject.org/users/ et http://fr.wikipedia.org/wiki/WebM .
Hey ,
Voici une démo de la balise <use /> en action. Cette balise permet d'utiliser des définitions de composants situés dans d'autres fichiers. Pour l'instant, l'interprétation de « l'instruction » <use /> est statique. Peut-être qu'elle deviendra dynamique à l'avenir. Je vais au plus simple pour l'instant .
Les exemples que je montre dans la vidéo sont les suivants.
On a notre fichier principal main.xyl :
<page>
<use href="contact.xyl" />
<contacts bind="?foo" />
</page>On notera que l'on veut utiliser contact.xyl en espérant qu'il contienne notre définition de composant <contacts /> (notez le « s »).
Notre fichier contact.xyl :
<definition>
<yield name="contact">
<p>
<ul>
<li bind="?firstname" />
<li bind="?name" />
<li bind="?email" />
</ul>
</p>
</yield>
<use href="contacts.xyl" />
</definition>Ah, on définit bien notre composant <contact /> mais pas <contacts />, mais on dirait qu'il se situe dans contacts.xyl (volontairement dans un autre fichier pour montrer que les <use /> peuvent être utilisés dans des définitions). Alors :
<definition>
<yield name="contacts">
<section1>Foobar</section1>
<contact bind="?" />
</yield>
</definition>On voit que <contacts /> utilise <contact />, que tous les <use /> fonctionnent etc.
Le résultat de notre exécution :
<!DOCTYPE html>
<html>
<body>
<h1>Foobar</h1>
<p>
<ul>
<li>Ivan</li>
<li>Enderlin</li>
<li>i@e</li>
</ul>
</p>
<h1>Foobar</h1>
<p>
<ul>
<li>Hend</li>
<li>Ksontini-Enderlin</li>
<li>h@k-s</li>
</ul>
</p>
<h1>Foobar</h1>
<p>
<ul>
<li>Titine</li>
<li>Enderlin</li>
<li>t@e</li>
</ul>
</p>
</body>
</html>Exactement ce qu'on souhaite.
Ce que je montre dans la vidéo (de 4mn) : si on édite notre composant <contact />, ça va se répercuter partout (normal et c'est un peu ce qu'on en attend).
Ce que j'ai oublié de montrer dans la vidéo : si on utilise <contact bind="?foo"> à la place de <contacts bind="?foo" /> dans main.xyl, on aurait :
<!DOCTYPE html>
<html>
<body>
<p>
<ul>
<li>Ivan</li>
<li>Enderlin</li>
<li>i@e</li>
</ul>
</p>
<p>
<ul>
<li>Hend</li>
<li>Ksontini-Enderlin</li>
<li>h@k-s</li>
</ul>
</p>
<p>
<ul>
<li>Titine</li>
<li>Enderlin</li>
<li>t@e</li>
</ul>
</p>
</body>
</html>Autrement dit : il va quand même boucler, mais utiliser <contacts /> permet d'ajouter de la décoration autour de nos éléments déjà existants. Si jamais vous utilisez un composant XYL déjà existant, vous pouvez le décorer/l'augmenter facilement. La modification plus en profondeur des composants va être attaquer dans pas longtemps (truc du genre <overlay />).
Le lien : http://j.mp/XYL_early_draft.
Hey ,
La balise <use /> est remplacée par la PI (processing instruction) <?xyl-use ?>. C'est plus logique à mon goût.
J'ai un peu galéré dû à un bug de PHP (http://bugs.php.net/52751) qui m'a pris un petit moment à contourner. Mais tout va bien. Je poursuis !
Hey ,
Dans le prochain très gros chantier de XYL, j'ai l'exécution de XYL en lui-même et les <overlap>. Je me lance sur l'exécution de XYL mais je voulais votre avis sur quelque chose.
Si je propose quelque chose comme XBL2 (voire XBL2 tout court) pour le système d'<overlap>, est-ce que ça couvient ?
Ou peut-être préférez-vous un système à la <overlay> de XUL ?
Liens :
• http://dev.w3.org/2006/xbl2/Overview.html
• https://developer.mozilla.org/en/XUL_Tutorial/Overlays
Hello,
Euh... deux petits exemples simplistes qui nous montrerait les différences principales?
Merci
Les overlays servent à ajouter du contenu alors que XBL sert à modifier le contenu. Ce sont des notions différentes .
Vouloir implémenter XBL2 me parait légèrement overkill!
Puis la partie <implementation> de XBL2 n'aurait pas trop de sens pour XYL.
Je suis d'accord qu'un system à la <overlay> de XUL risque d'être trop limité.
Je vais m'appuyer sur un cas pratique qui a déjà été proposé dans cette thread... normalement (je fais ça de mémoire) :
Un composant quelconque dans le XYL doit pouvoir "sélectionner" la partie <head> du doc et ajouter un <link rel="stylesheet">.
Déjà, truc con, je n'arrive pas à bien comprendre comment on fait ça proprement avec XBL2 sans passer par du scripting (qui serait dans la partie <implementation>).
Comment on fait ça avec <content> et <content includes=".."> ?
Juste ajouter le <link> à la suite des autres <link> potentiellement déjà présents dans le <head>, et sachant que <head> serait le bound element.
Les selecteurs dans (les) includes="" seraient complexes, non ?
Je pense à ça car j'imagine que XYL pourrait proposer une sorte de subset de XBL qui concernerait la partie <template> avec le <content> et les selecteurs. Techniquement, cela ne serait pas trop éloigné de ce qui est déjà implémenté dans XYL (je pense).
Pour reprendre les termes de XBL2, on aurait des shadow trees dont les déclarations resteraient à définir mais seraient proche de ce qui existe pour les yield.
Ensuite, une fois ces fragments isolés, il faudrait que leurs bound elements soient remplacés par leur final flattened trees respectifs. Opération qui se ferait avant le "liage" des données. C'est pas plus compliqué que ça 
Quoique..
A vu de nez, je dirais:
Pour chaque binding (dans le jargon de XBL), on sélectionne les bound elements. On se retrouve avec 2 dom fragments:
- shadow tree
- explicit children
On sélectionne avec xpath chaque <content includes=""> dans le shadow tree et on les remplace par les fragments qui matchent dans les explicit children. Pour bien faire les selecteurs dans les includes="" seraient des selecteurs CSS. Chaque élément matché est retiré du fragment des explicit children.
Puis on remplace les <content> du shadow tree par le fragment restant des explicit children.
Finalement on insert le flattened tree qu'on vient d'obtenir en lieu et place du bound element dans le doc.
C'est vite dit, car c'est quand même complexe cette histoire. Que faire si plusieurs bindings s'appliquent aux mêmes elements? Appliquer le <inherited> de XBL?
Est ce que des includes="" dans un même shadow tree peuvent s'appliquer aux mêmes explicit children plusieurs fois? Auquel cas il faudrait garder l'intégrité des explicit children et ça compliquerait un peu les choses pour les <content> qui n'ont pas de include="".
Le point positif du "principe" de XBL appliqué à XYL est que c'est orthogonal par rapport au reste: le liage et les yields. En tout cas, j'espère
edit: "orthogonal" par rapport au liage et au -rendering-. Car pour les yields, il me semble qu'ils devraient être traités avant le XBL..
Dernière fois dit par metagoto (03 Sep. 2010 22:49)
Je peux déjà implémenter les overlays car c'est facile et très pratique.
Imaginez que vous ayez une application développée avec XYL : vous voulez ajouter un module ; donc vous ajoutez un composant (des <yield> dans des <definition> par exemple) et vous fournissez des overlay pour hacker l'application existante : ajouter un item à un menu, modifier je-ne-sais-quoi etc. C'est le but des overlays et c'est quand même bien pratique (en tout cas dans Firefox).
Votre avis ?
On pourra voir pour une approche plus orthogonale, comme tu dis, dans une prochaine version. J'ai dit que j'allais faire une release de Hoa pour fin 2010, il faut que j'avance car le programme de mon Master 2 s'annonce bien chargé …
Posts [ 41 to 50 of 88 ]
Pages Précédent 1 2 3 4 5 6 7 8 9 Suivant
Vous devez vous loguer ou vous enregistrer pour poster une réponse
Hoa Forum » Actualités » Hoa_Xyl vient d'apparaître dans le tronc
Powered by PunBB
Currently used extensions: pun_repository, pun_bbcode, pun_pm, pun_quote, pun_antispam. Copyright © 2008 PunBB
[ Généré en 0.103 secondes, 18 requêtes exécutées ]