Forum: Rails France Manipuler le DOM avec Rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
50976bd08502aa0ac6e722828abb2379?d=identicon&s=25 Frédéric Jay (Guest)
on 2007-07-24 14:57
(Received via mailing list)
Bonjour à tous,

Dans le cadre de mon projet, j'ai besoin de manipuler le DOM.
Donc moi, gros bourin que je suis, je l'ai fait à l'ancienne, en
javascript.
(avec des document.getElementById.Childsnode[i]....)
On aurait parié la lune : Ca ne marche que pour Firefox (par défaut sur
mon
poste), et tintin pour les autres navigateurs.

C'est quand meme super dommage, car avec Rails, on peut :
- Se connecter à n'importe quelle base (Oracle, Mysql, SQLServer,...).
- Faire de l'AJax qui marche à tous les coups sur tous les navigateurs.
- Extrapoler avec les RJS
.....
Et finalement faire un vilain javascript qui rétrécit soudain toute la
portabilité :-/

Ma question est la suivante :
Est ce qu'on peut gérer le DOM avec des balises Rails ?
Est ce que dans l'affirmative il y a des contraintes ?
Faut-il un plugin ?

Merci d'avance pour vos réponses :)
400818411253800c62377dcac0b771d7?d=identicon&s=25 Yannick Francois (Guest)
on 2007-07-24 15:04
(Received via mailing list)
Le 24/07/07, Frédéric Jay<yajderf@gmail.com> a écrit :
> Dans le cadre de mon projet, j'ai besoin de manipuler le DOM.
> Donc moi, gros bourin que je suis, je l'ai fait à l'ancienne, en javascript.
> (avec des document.getElementById.Childsnode [i]....)
> On aurait parié la lune : Ca ne marche que pour Firefox (par défaut sur mon
> poste), et tintin pour les autres navigateurs.

> Ma question est la suivante :
> Est ce qu'on peut gérer le DOM avec des balises Rails ?
> Est ce que dans l'affirmative il y a des contraintes ?
> Faut-il un plugin ?
>

Pour commencer par faire mon enquiquineur (comme d'hab quoi) je
voudrais savoir pourquoi tu fait du DOM coté client ? coté serveur
çaserais plus simple, avec les divers librairies ruby qui existe pour
lire du xml. REXML, le binding libxml et j'ai entendu parlé de deux ou
trois autres qui sont interessante (hpricot ? plus pour le (x)html il
me semble).

Ca me parait en tout cas plus portable :-p. Maintenant j'ai peut-être
pas compris ce que tu cherchais a faire :-D


--
Yannick Francois
http://www.typouype.org
http://www.rubyfrance.org
139b66112d2e2b4efafac2aefed01c2f?d=identicon&s=25 Yann KLIS (Guest)
on 2007-07-24 15:20
(Received via mailing list)
Je suppose que tu veux manipuler le DOM du côté client, en Javascript
donc. Fort heureusement, Rails arrive avec le couple
Prototype/Scriptaculous qui te permettra de manipuler le DOM
facilement.

Voir la doc de Prototype : http://prototypejs.org/

++

yk

Le 24/07/07, Frédéric Jay<yajderf@gmail.com> a écrit :
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2007-07-24 16:19
(Received via mailing list)
> Je suppose que tu veux manipuler le DOM du côté client, en Javascript
> donc. Fort heureusement, Rails arrive avec le couple
> Prototype/Scriptaculous qui te permettra de manipuler le DOM
> facilement.

Clairement oui, regarde prototype, qui te donne une vraie portabilité
côté javascript:

ex:
http://www.prototypejs.org/api/utility#method-$
http://www.prototypejs.org/api/utility#method-$$
5189918b33297d2ac458a4c39ccb5a4a?d=identicon&s=25 c0rwin (Guest)
on 2007-07-24 16:23
(Received via mailing list)
Le petit DOM builder qui va bien dans script.aculo.us :

http://wiki.script.aculo.us/scriptaculous/show/Builder
140f1cb88275f7c391504de6e99edc78?d=identicon&s=25 Sébastien Gruhier (Guest)
on 2007-07-24 16:48
(Received via mailing list)
ou carrement sur le trunk tu peux faire des chose comme
çavar element = new Element('div', {id: id, className: 'dialog'});
50976bd08502aa0ac6e722828abb2379?d=identicon&s=25 Frédéric Jay (Guest)
on 2007-07-26 09:20
(Received via mailing list)
Waouh....Merci pour les réponses.
Ca répond completement à ma question, c'est nikel.

Et pour répondre à Yannick, pourquoi je cherche à utiliser DOM, j'avoue
que
c'est une trés bonne question.
Dans les faits, j'ai un tableau, pour gérer des parcelles de terrains.
(numero, section, surface,..)
- Pour des questions d'ergonomie, j'ai implémenté dessus
in_place_editor_field afin de pouvoir modifier les valeurs directement
dans
la page.
- Pour créer une nouvelle parcelle, j'utilise RJS et donc pas besoin non
plus de recharger la page.
- Enfin, j'ai implémenté aussi dessus une lib javascript, pour trier les
colonnes, lorsqu'on clique sur l'entete.
Mon besoin : calculer le total des surfaces à la volée et l'afficher
dans la
derniere ligne du tableau.

J'ai utilisé DOM pour pouvoir récupérer les valeurs directement dans la
page, et afficher le résultat.
J'ai préféré aussi faire travailler le poste client, plutot que le
serveur.
Ca m'a semblé lourd pour le serveur de se recogner la requete de calcul
à
chaque fois...
Mais peut etre est-ce maladroit ?



Le 24/07/07, Sébastien Gruhier <sgruhier@gmail.com> a écrit :
400818411253800c62377dcac0b771d7?d=identicon&s=25 Yannick Francois (Guest)
on 2007-07-26 09:31
(Received via mailing list)
Le 26/07/07, Frédéric Jay<yajderf@gmail.com> a écrit :
> Mais peut etre est-ce maladroit ?
>
>

Non pas forcement :-)
Je voulais juste être sur que tu avais choisi en connaissance de cause
la façon dont tu travail (coté client donc) :-).


Ceci dit...

> J'ai préféré aussi faire travailler le poste client, plutot que le serveur.
> Ca m'a semblé lourd pour le serveur de se recogner la requete de calcul à
> chaque fois...

Un serveur c'est fait pour ça normalement. Disons qu'aujourd'hui les
postes client sont souvent plus puissant que certain serveur alors
çafait bizarre.

Je dirais plutôt que ça évite de faire trop d'aller retour et donc de
pourrir le réseau, mais c'est une façon de voir :-p.
On pourras voir un resultat où c'est à usage (privée|pro) && confidentiel ?


--
Yannick "Pouype" Francois
http://www.typouype.org
http://www.rubyfrance.org
2fb6ebf03db24142b31d00edf4ab73b2?d=identicon&s=25 TslH (Guest)
on 2007-07-26 09:38
(Received via mailing list)
Le 26/07/07, Yannick Francois <yannick.francois@gmail.com> a écrit :
> Un serveur c'est fait pour ça normalement. Disons qu'aujourd'hui les
> postes client sont souvent plus puissant que certain serveur alors ça
> fait bizarre.
>
>
Disons qu'une autre approche serait plus cohérente: garder tes calculs
et
validation sur le client, mais tout de même ré-effectuer les tests et
calculs lors du post final sur le serveur: ainsi d'un coté tu enlèves
les
va-et-vient réseau puisque les clients "conformes" effectues tout le
travail
de "mise au point" des données, et cela protège ton serveur de données
corrompues ou inappropriées.

HTH.
This topic is locked and can not be replied to.