Reprise du message précédent :
@El_gringo : Pour info, c'est le même fonctionnement que php par exemple

 
C'est Dave Thomas qui parle d'url rewriting dans ce contexte. En gros il dit que ça existe, mais pas avec Rails. Sinon je sais ce que designe l'url rewriting habituellement, mais après tout, dans ce cas là aussi il s'agit de réécrire l'url (là, c'est en y ajoutant un paramètre), donc pourquoi pas "url rewriting"...
 
Et puis, pourquoi tu dis que c'est moisi le jsessionid ? Moi je trouve ça bien pratique si tu veux que ton appli soit accessible (sessions comprises) sans cookies. En J2EE, cette façon de maintenir les session n'est utilisé QUE si les cookies ne sont pas pris en charge par le client.
 

 
C'est vers la page 100 du bouquin (seconde édition). Pour ta remarque à propos de cookies[] et session[], masklin t'a déjà répondu.
 

 
Php est loin d'être exemplaire à mes yeux ! :-P

 
Ouais mais bordel, je sais très bien que ce n'est pas la même chose  
 

T'as bien raison
Ps : C'est "Pratique de Ruby On Rails" par Oreilly que j'ai, Agile est pas arrivé encore  

L'URL rewriting ou l'ajout de sessionid and l'URL? parce que dans Rails toutes les urls sont "rewritées" (via routes)

Ouais, et tu flinques tes URLs violement, et ça facilite dramatiquement le vol de session

 
ça veut dire que j'aurais mal compris ce que dit Dave Thomas dans son bouquin ? (vers la page 100)
 
Et mes url "flinguées" elles fonctionnaient très bien en J2EE !

Aucune idée, je sais pas de quel bouquin tu parles et je suis pas chez moi

Ce que je voulais dire c'est qu'elles sont supermoches, et que c'est la dèche pour les filer à quelqu'un d'autre

Il lit "Agile Web Development with Rails"

Ok je l'ai chez moi, donc si on me le rappelle je pourrais peut-être regarder ce soir

Rappel?

Hop c'est je présume la partie Chapter 8 task C sur mon bouquin (1er edition).
 
Et donc c'est bien ce que moi et Shinuza disions: DHH et Dave Thomas (le bouquin est écrit à deux hein ) écrivent une introduction aux sessions, indiquent que les deux moyens d'encoder les identifiants de session sont le passage via l'URL (donc à la jsessionid) et les cookies, et que Rails utilise l'approche basée sur les cookies, donc que l'utilisateur a besoin d'avoir les cookies activés.
 
Sous entendu: si les sessions sont nécessaires pour ce qu'il fait naturellement, si elles ne le sont pas on s'en fout

Donc, El_gringo, je ne sais pas si tu fais du Php ou pas (volontairement pas ou pas hein ), mais par défaut php transmet également l'identifiant de session via les cookies, donc y'a rien de choquant (et c'est aussi le cas pour ce forum )

 
Le bouquin, c'est Agile Web Dev, 2nde édition. Et c'est vrai que moi aussi j'attache beaucoup d'importance à l'esthétique des mes url. D'ailleurs j'éspère que bientôt on pourra y mettre des smileys et plein de couleurs. Plus sérieusement, il y a sans doute des bonnes raison à la non-implémentation de cette fonctionnalité dans Rails, mais je doute que ce soit un critère esthétique.

 
Et ils appellent pas ça "url rewriting", quand ils parlent du passage via l'url ?
Sinon, c'est aussi ce que j'avais compris. Je posais pas de question à la base, je disais juste que ça m'étonnait (et me gênait un peu) de ne pas avoir de possibilté de maintenir une session autrement que par des cookies.
 

 
Pas de php, non (oui, c'est un choix). La seule techno que j'ai utilisé avant de tenter le coup sur Rails, c'est Java, qui, LUI, permet au pire, de maintenir des session sans cookies (= par ajout d'un paramètre d'url). C'est pour ça que je m'étonnais.

Non l'url rewriting permet de "nettoyer" l'url en passant des paramètres autrement que par une query string classique.
 
Dans tout les cas, le passage de l'id de session via l'url c'est à chier, pour des raisons plus qu'évidentes

À mon avis, il y a pourtant 150% de chances que ça en soit un

Ils nomment ça comme ça, je ne considère pas que ça en soit, c'est juste le passage du sessionid en paramètre get.

Le fait est qu'on ne peut pas, et que ce n'est à mon sens pas un problème

 
J'ai déjà dit que je sais bien ce qu'on désigne en général quand on parle d'url rewriting.
 

 
Ha, il me semblait bien qu'ils écrivaient ça.
Bon, pour moi c'est un peu un problème, j'aime bien avoir une solution de secours, même si elle n'est pas super clean. Tant pis, je ferais sans. Je vais pas laisser tomber Rails pour ça non plus !

Seabee, tu devrais peut être éditer la première page, pour annoncer une grande nouvelle : la récupération du projet RadRails par l'équipe d'Aptana, ce qui est d'excellent augure. http://www.aptana.com/

Sortie (plus très récente) de InstantRails aussi

Ok, bonne nouvelle effectivement. Donc Aptana est un IDE javascript/css/xhtml sur eclipse? Et ils vont fusionner les deux projets à terme?
Je mets à jour.

Oui, Aptana est un IDE Web (côté client) basé sur Eclipse. On peut l'installer comme plugin Eclipse, mais aussi en Standalone. Je le trouve vraiment très très bien foutu, à essayer, vraiment. Voici le feuille de route de l'intégration de RadRails à Aptana (ou le contraire) : http://radrails.net/radrails.php

Certains ont lu "Agile web developpement with Rails, 2nde édition" ? (c'est pour discuter d'un truc).

Il est en route vers chez moi, mais j'ai lu des extraits, pose toujours ta question, masklinn l'a chez lui

Ok. ça concerne le Playtime (quelques exercices pour vérifier les acquis) de "Task D : Add a Dash of AJAX". On a créé le Panier et on peut désormais y ajouter des éléments en exploitant (si javascript activé) des méthode de type AJAX. Le panier ressemble à ça :

 
L'exercice, c'est d'ajouter, pour chaque ligne du panier, un bouton "retirer", qui décrémente d'une unité le nombre d'occurrences d'un produit dans le panier, et supprime celui-ci du panier, si ce nombre passe à 0.
On trouve une solution au problème sur un Wiki en ligne, mais elle me semble moyenne : j'ai l'impression que cela fait faire un appel SQL qui n'est pas nécessaire, et ne devrait donc pas être fait. En effet, on récupère un produit en base de données (product = Product.find(params)), alors qu'on dispose déjà de toutes les infos concernant le dit produit, dans chaque instance de CartItem. Non ? Par contre je suis encore bien débutant en Ruby et j'avoue que j'ai du mal à mettre en oeuvre ce que je dis...

Non moi j'ai la première édition

je suis pas sur que ce soit ça, mais regarde regarde du côté des compteurs (chapitre 18.9, page 359)
j'ai pas lu le Playtime (j'avais déjà lu Pratique de Ruby On Rails), donc je sais pas exactement ce que tu veux faire ...

 
Ha, zut !    
 

 
Non non, le compteur c'est peut être adapté, mais le principe de ces Playtimes, c'est de mettre en oeuvre les concepts qu'on vient d'aborder dans le chapitre, donc il ne s'agit pas d'aller chercher des trucs ailleurs, sinon c'est tricher !

le problème, c'est que chaque requête crée une nouvelle instance du controleur, donc tes données n'existent plus que dans ta page html ...
par contre, tu peux utiliser les méthodes update ou update_all, ça peux éviter des requêtes inutiles

C'est sympa d'essayer de m'aider, mais je crois vraiment que c'est pas simple de comprendre la situation si tu n'as pas lu le bouquin. En l'occurrence, les données auxquelle je fais allusion : instance Cart contenant des instances de CartItem sont stockées en session. Ce n'est pas forcément très bien, mais c'est fait comme ça dans leur tuto. Donc autant en profiter pour faire un minimum de requètes en BD.

ha oui, j'oubliais les sessions
effectivemnet, dans ce cas, pas besoin de Product.find
en fait, il faudrais utiliser les méthodes d'instance de la classe Array (http://www.ruby-doc.org/core/classes/Array.html)
par exemple avec each :

def remove_product(product_id)
  for item in @items
    if item.product.id == product_id
      if item.quantity > 1
        item.decrement_quantity
      else
        item = nil
      end
      break
    end
  end
  @items.compact # on supprime tous les éléments nul
end

on doit pouvoir faire plus propre, mais voila une piste ...

edit : avec une boucle for c'est mieux, on peux sortir de la boucle une fois l'item trouvé

Oui, dans l'idée c'est qqch comme ça (sauf qu'il te manque quand même le moment où on récupère le panier depuis la session). Mais dans cette voie, j'avais justement implémenté qqch et n'arrivais pas à le faire fonctionner. Je posterais ça demain.

@cart = find_cart
@cart.remove_product(params[:id)

dans ton action

J'ai publié ma solution en fin de la page du Wiki. Vous êtes pas d'accord avec moi ?
 
Par contre, dans les solutions proposées par les autres (et qui complètent ce que je propose), y a un truc que je comprend pas au niveau de l'AJAX :  
j'ai l'impression que dans la 1ère solution (par "Nicolas" ), il manque la partie de mise à jour du DOM (dans un fichier remove_from_cart.rjs), non ?
Sinon, dans la solution proposée par k9d, avec l'utilisation du helper link_to, chez moi ça lance une requète HTTP "normale", donc impossible de faire de l'AJAX. J'avoue que je m'y paume un peu dans toutes ces solutions. Seul un mix de ces dernières m'a permi d'arriver à un résultat satisfaisant.

ça me sembles correct
par contre pour la partie AJAX, je saurais pas t'aider, j'en ai pas encore fait avec Rails
pour la solution de k9d, est-ce que c'est la requête ou la réposne qui est en http normal ?
essaye en ajoutant :format => :xml en paramètre du link_to, mais il faut, je penses, également gérer le cas dans ton action (redirect_to_index unless request.xhr? dans la première solution)

edit : en fait, y a un helper pour ça, link_to_remote http://rails.rubyonrails.com/class [...] ml#M000527

Je sais qu'il y a un helper pour ça, mais ça voudrais dire que la "solution" proposée par ce "k9d" est tout simplement fausse ?
Et le problème du helper "link_to_remote", c'est qu'apparement il ne fonctionne que si javascript est activé sur le navigateur client. Pour palier à ça, "Bradford Chang" propose de faire :

Mais ça fait écrire deux fois les mêmes infos. Par trop dans l'esprit RoR...

Tu crées un helper qui les combine, il y en a même probablement déjà

Ce serait étonnant d'avoir à écrire un helper pour un truc aussi banal. Mais je ne trouve rien dans la doc qui les combine, comme tu dis.

Les solutions ajaxy ne font pas partie du core initial de Rails (ça a été ajouté en standard dans Rails 1.0 ou 1.1), donc on ça n'a rien d'étonnant

Salut à tous,
 
Je me pose la question de l'internationalisation sous Rails. J'ai commencé à lurker du côté de Globalize et Localization, mais j'ai également vu qu'à terme, une solution serais évidemment intégrée à Rails.
 
Pour quelle solution (la plus pérenne possible) opter pour le moment ? Si vous avez des tutos ou articles sympa sur le sujets, je prend aussi.
 
Edit : un bon tuto sur Globalize

y a gettext aussi : http://manuals.rubyonrails.com/read/book/16
mais c'est pas très simples a mettre en place

J'suis en train de me pencher sur GLoc moi http://rubyforge.org/frs/?group_id [...] se_id=9613 ca à l'air sympa, pas mal de features sans que ca devienne l'usine à gaz.

Le temps de RoR est passé, vive Python on Planes (Supersunday Release)!

Lu sur le site:
- Web development that doesn't suck
- The software development world is moving towards AGILE DEVELOPMENT, WEB-2.OH, GURU PRESENCE and LEAN SOFTWARE. Our Framework is geared to support all these features.