Reprise du message précédent :

 
J'ai utilisé awesome_nested_set pour mettre en place un système de commentaires imbriqués, pas de soucis chez moi

Tu as mis des clé uniques sur les champs "lft" et "rgt" ?

 
De tête je sais plus, bcp d'index sur les parent, lft et rgt je crois mais une clé unique je suis pas sur.
Je te confirme demain du boulot devant le code

J'ai utilisé awesome_nested_set et better_nested_set. Les deux sont des drop-in replacement l'un de l'autre, donc pas difficile de tester les deux (avec les mêmes données).

Awesome nested set n'a pas de full_set, de reorder_children(ids) et de move_to_top|bottom qui sont bien pratiques. (mêmes si ont peu se démerder sans eux.)

Sinon leurs codes est tellement semblable...

Je recommanderai pas de mettre des clefs uniques sur left et right, par contre. On sait jamais si ça peut pas foutre la merde un jour

Pour les index
  t.index [:parent_id, :lft]
  t.index [:lft, :rgt]
ça couvre 99% des cas.

Parce que cette histoire ça m'inquiète. Théoriquement j'ai le droit de mettre cette clé unique sur ces valeurs, vu qu'elles doivent être uniques. Du coup je me demande si le plugin fait pas quelques tour de passe-passe qui risque de mettre en péril la cohérence des données

Ce sont pas des plugins de guignols

Je confirme, pas de clé unique non plus ici

D'accord mais vous pensez pas que si l'index unique gueule dès que je crée un noeud, c'est qu'il y a des problèmes potentiels ?
Moi j'ai un peu peur que si on commence à avoir plusieurs insert/delete concourants, la cohérence des données soit mis en péril .. Vous en pensez quoi?

Je sais pas trop il faudrait regarder ce qui se passe a l'insertion d'un nouvel élément mais ca me parait pas scandaleux d'imaginer que dans la logique de construction de l'arbre, à un moment, les lft et rgt soit pas uniques.

Je sais pas. Moi ça me semble une bonne manière de protéger la base de donnée .. Je vais voir si ça passe sans mettre de contrainte unique comme l'a dit seabee.
Je vais tester aussi la version "better" histoire de voir
merci à vous deux

Je viens de me créer un compte un tadalist, et je comprends pas le hype qu'il y a eu autour. C'est pas terrible. Je trouve que remember the milk est plus ergonomique.
 
EDIT: ha ok avec tadalist on peut faire du "social todo list", mouais.

Est-ce que Rails permet de facilement activer et désactiver une partie d'un formulaire selon le choix d'un dropdown box?

 
Dites voir... Même question mais avec SSL obligatoire (paiement en ligne), mais surtout pour voir si vous avez des retours sur une entreprise française ? J'aime bien prendre mon téléphone quand ça merde, donc au cas où.
 
Merci

Haut de gamme, je connais Typhon qui fait du bon boulot. Ils font de la TMA de luxe pour Rails. Mais c'est pour du besoin spé, pas une offre packagée. Et c'est cher.
 
Sinon en France je sais pas. Aux USA Linode et Slicehost remportent tous les suffrages pour le virtuel.

Rien à voir avec Rails. C'est du JavaScript.
Écoute l'évènement 'onchange' sur ton select, et modifie la visibilité de ses dépendances en conséquence.
Tu peux le faire plus facilement avec Prototype/jQuery ou directement sans FrameWork.

Merci je savais que c'était du javascript, je pensais que Rails aurait un helper tout prêt pour ça mais je n'en trouvais pas, donc je vais faire ça en prototype raw.

Est-ce quelqu'un arrive à gérer les centimes (enfin les chiffres après la virgule)? C'est beaucoup plus compliqué que ça en a l'air. Tout ce que j'ai tenté pour le moment est assez laid.

En général en programmation on ne gère que des centimes quand on gère des problèmes monétaires, que l'on convertit simplement à l'affichage, ca permet d'éviter tous les problèmes liés aux nombres flottants.

 
J'avais vu Typhon effectivement, j'ai même pas osé demander un devis Merci pour ton retour.

Merci tu m'as mis sur la voie de la solution!    Alors j'ai tenté un tour de passe-passe avec un before_save pour *100 et ensuite dans la view je divise par 100 et je tronque les 0 des décimales s'il y a lieu. Pour le moment j'ai pas encore trouvé d'edge case qui plante ce concept. J'écrirais un bel article à ce sujet une fois que tous mes tests seront au point et que ça marche à 100%. EDIT: Fail, dans le before_save, les décimales ont déjà été tronquées car l'attribut est un integer    EDIT: un truc est de créer un helper.
 
Sinon ça intéresserait quelqu'un que je pluginify mon générateur de graphique en barres verticales en pure html+css? J'ai créé ça parce qu'Open Flash Chart fait leaker la mémoire de mon FF 3.6 et sature toute la mémoire vive en à peine 1 seconde    C'est super limité forçément, néanmoins ça fait son boulot proprement

Au USA en mutualisé tu as dreamhost en vraiment pas cher

l'option :add_month_number => true n'est pas prise en compte dans mes date_select. J'ai fais une faute de frappe ou c'est pareil pour vous?

C'est désormais officiel, awesome nested set est une grosse    
 
Gros effets de bords bizarres et suspects avec cache-money, le genre de bug qui met pas du tout à l'aise.
Je viens de switcher sur better, plus aucun soucis.
 
C'est pas la première fois que je me dis que awesome pue des baskets. J'en ai fini d'essuyer les plâtres.

En pratique attr_accessible c'est un peu pénible. Est-ce que certains d'entre-vous font du filtrage au niveau du controlleur plutôt?

avec attributes= on peut bypasser attr_accessible

attributes=({attrs_hash}, false)
Mais en général, ils sont protégés pour une raison
En tout cas ça ressemble à du code-smell.

Côté admin et dans les tests c'est assez saoûlant de devoir taper:
 

Mais bon si on ne tape pas de tests, on ne s'en rend pas compte  

 
Bof pour les tests t'as factory girl et autres

Dans le cas de la STI, est-ce que l'attribut "type" est protected automatiquement? Parce que j'ai un modèle et je n'arrive pas à changer son attribut type et je ne comprends pas pourquoi.
 
EDIT: oui c'est auto bloqué.  

J'ai un petit problème de SQL injection. Je désire dynamiquement générer la requête suivante:

Mais ça ne marche pas.
 
Par contre la requête suivante fonctionne mais est ouverte aux injections:

 
Quelqu'un a une idée comment éviter l'injection SQL? je pourrais utiliser une regexp pour filtrer attribute, mais si quelque chose de plus propre existe je suis preneur.
 
Merci d'avance  

Je te conseille searchlogic
Tu as même un railscast dessus http://railscasts.com/episodes/176-searchlogic

Bof pour searchlogic, je préfère hardcoder mes named_scope.
 
Sinon somme solution je filtre mon attribute en le comparant aux noms de colonnes du Model sur lequel se fait la recherche, ça me suffit comme protection.

Le STI me casse souvent les pieds en ce qui concerne la génération d'url. Ex:
 
Product < AR
Membership < Product
 

Va vouloir poster le formulaire à MembershipsController, mais si je veux poster à ProductsController je fais comment? Je fourni l'option :url, mais si ce même formulaire gère la création et la mise à jour d'un objet, il faut gérer #create/#update avec des if moches, ou alors sortir le form_for du partial _form.html.erb, mais bof.
 
Ma solution pour le moment est de tricher, et de renommer la colonne "type" en "kind" et de gérer ça à la main avec des if kind == "Membership". C'est assez propre, mais si vous avez mieux à proposer pour recycler les controlleurs dans vos models en STI je suis preneur.  
 
EDIT: une solution serait de résoudre ce petit souci:
 
Je sais que le product avec id 10 a un type "Membership"
 
Product.find(10) => ça me renvoit un objet de la classe Membership, ce que je ne voulais pas.
 
Y-a-t'il un moyen de dire à Rails que lorsque je fais Product.find(10) je veux un objet de classe Product même si je sais que c'est un Membership?
 
EDIT: Yep j'ai trouvé!

Je connaissais pas, et c'est vachement pratique avec le STI  

Si tu whitelist tes attributs accessibles oui. Sinon méfiance sur un site exposé.  

Objectivement, Searchlogic est une tuerie. S'en passer c'est souffrir inutilement. Il te fait gagner un temps de dingue niveau formulaire de recherche (suffit par ex. de donner comme name un simple 'first_name_like_or_last_name_begins_with' et il gère tout le bouzin sans coup faillir. Sans compter que tu peux passer tes propres named_scopes dans ton formulaire de recherche
C'est un des trucs les plus classieux que j'ai vu depuis un certain temps. Sans compter que la doc tient sur une page et couvre tous les cas... En 6 mois d'utilisation je n'ai pas eu envie de soumettre un seul patch, c'est un peu une première

Une solution pour tes forms c'est de faire un helper qui gère ton form_for avec tous les cas.
Sur le fond tu as raison, et c'est pas le seul soucis avec la STI, loin s'en faut. C'est le résultat d'une cabale un peu zarb qui date d'il y a bien 4 ans. Depuis ce temps jadis, les patchs proposés pour résoudre les inconsistances d'ActiveRecord avec la STI avaient tendances à moisir un poil. Ca va mieux depuis quelques temps. Je pense que ActiveRecord 3.0 sera plus STI-friendly.

Sinon dans cet ordre d'idée je suis en train de virer toutes les actions edit/new de mes controllers/vues dans mon Back-office.
Du coup, pour faire un new, je fais un show de new, genre admin_articles_path(:new) et admin_articles_path(@article) pour le edit.
Le new/edit du controller ressemble à un simple

Et je n'ai plus de render :form avec de la duplication de code.
L'idée m'est venu quand j'ai réalisé que dans le BO, le edit avait tendance à remplacer le show, et que le form du edit et du new se ressemblait de plus en plus, pour de bonnes raisons.

C'est bien plus Restful

Certains sont passés sur Rails3 ici ? (git ou beta2 ?)

Testé en speed ce w-e, j'ai galéré avec RVM pour installer la "preview-2" de ruby1.9 (quitte à etre "on the edge" autant y aller pour de bon...).
J'ai fini par m'en sortir et j'ai réussi à "porter" un début d'appli qui tournait sous la beta1.
 
Pas eu le temps de fouiner plus que ça  pour le reste.

J'y toucherai pas avant la RC et une compatibilité totale avec Ruby 1.8.7
Perte de temps potentielle énorme.

 
Je confirme, ca pique en ce moment au niveau des gems, de la doc et tout  

 
pluzun, mais ca reste sympa pour geeker, et se préparer, RVM bien utilisé ( http://lindsaar.net/2010/3/31/bundle_me_some_sanity ) permet d'éviter pas mal de problèmes quand même, mais c'est clairement time consuming

Pour le moment, je préfère me préparer en passant mon appli en cours de dev sous bundler et en vérifiant la compatibilité des plugins.
Et je refuse catégoriquement l'amalgame Rails3 + Ruby 1.9
 
Une source d'emmerde à la fois, merci.

J'ai appris rails il y a 2 ans, j'ai l'impression que je dois tout réapprendre tellement ça a changé