Bonjour,
savez-vous si des projets visant à intégrer DojoToolKit à Rails
existent ? Ce framework me paraît très très intéressant à première
vue, notamment les widgets. Quelqu’un l’a déjà utilisé ?
Bonne journée.
Nicolas C.
Hello !
Je ne connais pas de projet visant à intégrer Dojo à Rails. Mais ça
reste du Javascript, et ça s’intègre simplement dans n’importe quelle
appli web. AMHA, le principal désavantage de Dojo c’est que ça fait tout
et même le café. Si tu veux te servir que d’une seule “feature”, c’est
un peu compliqué au départ à prendre en main (même si ils essaient
d’améliorer ce point).
Bref, de mon point de vue certaines features sont très bien, mais dans
l’ensemble, ce n’est pas tout à fait l’idée que je me fais d’une
solution “agile”.
Je l’ai utilisé sur http://whiteboard.novelys.com/ (désolé pour la pub,
mais là on me tend la perche), mais uniquement dojo.gfx.* qui est le
package destiné à l’affichage 2D (utilisant VML sous IE, et SVG sur les
navigateurs le supportant).
++
yk
Le jeudi 16 novembre 2006 à 10:45 +0100, Nicolas C. a écrit :
Le 16 nov. 06 à 10:52, Yann K. a écrit :
Hello !
Je ne connais pas de projet visant à intégrer Dojo à Rails. Mais ça
reste du Javascript, et ça s’intègre simplement dans n’importe quelle
appli web
Ok très bien, donc je n’aurai pas d’helpers mais ça s’arrête là. Je
peux aussi bien utiliser Mootools ou tout autre framework en prenant
soin de ne pas charger Prototype et Scriptaculous, je suppose que ça
rentrerait en conflit …
Bon très bien alors, il faudra que je fasse des essais avec les
différents frameworks que j’ai
trouvé.
Merci !
Nicolas C.
Pour ce que j’en ai utilisé (à prendre donc avec un “grain de sel”), les
2 n’entraient pas en conflit, mais c’est effectivement un risque
important.
++
yk
Le jeudi 16 novembre 2006 à 10:59 +0100, Nicolas C. a écrit :
2006/11/16, philippe lachaise [email protected]:
Question subsidiare :
Qu’est-ce qui, à votre avis, rendrait désirable d’utiliser, avec RoR, Dojo
ou un autre à la place de Prototype/Scriptaculous ?
XUL
Une faiblesse de la solutions standard ?
Un PLUS majeur d’une des solutions alternatives ?
Les solutions standards à base de JS c’est essayer de faire ce que
permet
une application desktop en web. Une hérésie et un casse tête chinois
même
avec une librairie JS … Essaye de faire un treeview pour voir…
L’avantage de XUL c’est qu’il a été créé pour ça, un treeview en XUL
c’est
quelques lignes de codes. Le problème c’est qu’il est spécifique au
moteur
gecko donc Firefox.
Question subsidiare :
Qu’est-ce qui, à votre avis, rendrait désirable d’utiliser, avec RoR,
Dojo
ou un autre à la place de Prototype/Scriptaculous ?
Une faiblesse de la solutions standard ?
Un PLUS majeur d’une des solutions alternatives ?
L’avantage de XUL c’est qu’il a été créé pour ça, un treeview en XUL c’est
quelques lignes de codes. Le problème c’est qu’il est spécifique au moteur
gecko donc Firefox.
Entre un casse-tête chinois et une solution qui en fonctionne que sur
un seul (enfin pas tout à fait) navigateur …
Le choix est malheureusement
limité.
Ou alors, il ne faut pas essayer de copier ce qu’on fait sur le Desktop
(un autre casse-tête commence alors).
++
yk
Le jeudi 16 novembre 2006 à 11:16 +0100, Frédéric Logier a écrit :
Bonjour,
En ce qui me concerne l’interet de dojo je le trouve dans les widgets
graphique et les layouts. Pour ce qui est du DOM ou des effets le couple
Prototype/Scriptaculous suffit.
philippe lachaise a écrit :
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
–
Mickael GERARD
Solutions & Technologies
ANYWARE TECHNOLOGIES
Tel : +33 (0)561 000 661
Fax : +33 (0)561 000.655
XUL … Le problème c’est qu’il est spécifique au moteur gecko donc
Firefox.
Ben oui, justement, ça le condamne à des applis spécialisées (hélas !).
Je recentre donc ma question :
Quelles son les raisons de préférer d’autres librairies PUR AJAX ?
Essaye de faire un treeview pour voir…
J’en ai fait un, un peu spécial. J’en ai bavé
Le jeudi 16 novembre 2006 à 11:23 +0100, philippe lachaise a écrit :
Je recentre donc ma question :
Quelles son les raisons de préférer d’autres librairies PUR AJAX ?
La supériorité technique ? L’éventail de fonctionnalités plus
importants ?
Par exemple, on me vante souvent les mérites de JQuery (qui n’a pas
oublié d’avoir une documentation dès le départ) :
++
yk
Le choix est malheureusement limité.
Getting Real !!!
peut-etre que la solution passe d’abord par une bonne analyse du besoin
: le treeview (pour reprendre l’exemple) est-il
si indispensable à l’application ?
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres !
Guillaume B. : (05 61) 19 40 65 / bureau S723
Ca dépend énormément du contexte. Si c’est une application utilisée en
interne et que tu peux imposer la plateforme cliente (Firefox par
exemple), pourquoi ne pas prendre XUL ?
De même, tu peux aussi proposer une interface supplémentaire à ton
logiciel fonctionnant XUL, afin d’offrir une solution légère (“pure
web”) pour tous les navigateurs et une interface un peu plus costaud (en
XUL) pour les navigateurs qui le supportent.
++
yk
Le jeudi 16 novembre 2006 à 11:35 +0100, Julien ALEXANDRE a écrit :
Je parlais de façon général en fait …
Pour moi si une solution ne sera utilisable que par une partie des
visiteurs, alors elle n’est pas envisageable.
Donc le choix est limité car il n’y a pas vraiment de choix a faire …
Un cas d’utilisation de XUL que je sens bien :
Le module d’admin d’un application un peu complexe.
Ce qu’on ne peut pas imposer aux utilisateurs (Firefox) n’est pas un
problème pour le/les administrateur(s)
Quelqu’un connait un exemple d’intégration RoR/XUL ?
2006/11/16, philippe lachaise [email protected]:
Un cas d’utilisation de XUL que je sens bien :
Le module d’admin d’un application un peu complexe.
Ce qu’on ne peut pas imposer aux utilisateurs (Firefox) n’est pas un
problème pour le/les administrateur(s)
Exactement, pour un BackOffice, par définition réservé à un nombre
restreint
d’utilisateurs, XUL est idéal.
Quelqu’un connait un exemple d’intégration RoR/XUL ?
Ceci http://www.zedshaw.com/projects/cookbooxul/index.html mais rien
d’officiel il me semble …
Le 16/11/06, Guillaume B.
[email protected]
a écrit :
Quand on en vient à imaginer de supprimer un widget de base comme le
treeview, je pense que cela démontre par a + b qu’il est stupide
d’imaginer
remplacer une application desktop par une application web.
Bref quand le buzz se sera calmé, on finira sans doute pas comprendre
que
les applications web ne peuvent être que complémentaire 
L’avenir c’est certainement l’intéraction d’appli desktop à des
webservices,
ou simplement utiliser des applets java …
les applications web ne peuvent être que complémentaire
La frontière entre les Web pur et le client riche est définie à un
moment
donné par le degré de sophistication atteint par les technologies
conformes
aux standards.
Aujourdhui la frontière c’est Ajax + CSS 1.5.
Si on mesure le chemin parcouru (en 2000 Netscap 4 était encore un
standard
fort ! Il s’étanglait sur CSS 1.0) on voit qu’Ajax est du client riche
par
rapport à hier.
Imaginons, par exemple, qu’au lieu de s’obstiner à pousser Javascript
plus
loin qu’il ne peut aller on standardise des bindings Browser/Language.
On pourra écrire qqchose comme :
Et hop on télécharge de façon tranparente le Ruby pour la plateforme et
les
gems standard et roule : plus besoin de faire des contorsions
d’écriture
pour hériter d’une pseudo-classe Javascript.
On finira bien, également, par avoir SVG, xforms, etc.
Tout ça pour d’ire que la fusion du Web est du desktop est inévitable.
C’est
lent car ça ne peut pas avancer plus vite que les standards mais dans 5
ans
on y sera, je prends les paris !
(en 2000 Netscap 4 était encore un standard fort !)
tellement que chez certaines boites c’est malheureusement encore le
standard (regarde mon “X-Mailer”) !!!
(-:
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres !
Guillaume B. : (05 61) 19 40 65 / bureau S723
Bref quand le buzz se sera calmé, on finira sans doute pas comprendre que les applications web ne peuvent être que
complémentaire
entièrement d’accord !!!
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres !
Guillaume B. : (05 61) 19 40 65 / bureau S723