Manipuler le DOM avec Rails


#1

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 :slight_smile:


#2

Le 24/07/07, Frédéric Jayremoved_email_address@domain.invalid 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 :smiley:


Yannick F.
http://www.typouype.org
http://www.rubyfrance.org


#3

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 Jayremoved_email_address@domain.invalid a écrit :


#4

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-$$


#5

Le petit DOM builder qui va bien dans script.aculo.us :

http://wiki.script.aculo.us/scriptaculous/show/Builder


#6

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 removed_email_address@domain.invalid a écrit :


#7

ou carrement sur le trunk tu peux faire des chose comme
çavar element = new Element(‘div’, {id: id, className: ‘dialog’});


#8

Le 26/07/07, Frédéric Jayremoved_email_address@domain.invalid a écrit :

Mais peut etre est-ce maladroit ?

Non pas forcement :slight_smile:
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


#9

Le 26/07/07, Yannick F. removed_email_address@domain.invalid 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.