Utilisation des named_scope

Bonjour,

Une question de
faisabilité:- j’ai un modèle sur lequel j’ai défini plein de named_scoped pour
pour voir faire des recherches.

  • j’ai une form sur laquelle l’utiliseur peut saisir ses citères de
    recherche (checkbox, sélection, texte, …)
    sachant qu’à chacun des critère correspond un named_scope

Quelle est la meilleure façon de construire ma recherche?
Est ce que je peux renseigner une string et une fois que j’ai parcouru
tous mes critères utiliser les named_scope? du style :
condition = “”
if criteria1
condition = condition + “.named_scope1”
end
if criteria2
condition = condition + “.named_scope2”
end

et ainsi de suite et faire à la fin
@model = Model.condition (si oui quelle est la syntaxe?)

Merci
Nicolas

Disons, il va falloir faire très attention aux exploits parce que ça
veut
dire donner une marge de liberté assez importante que tes utilisateurs
peuvent utiliser pour insérer potentiellement du code malicieux ou
détourner
ton outil de son objectif. Mais si tu veux faire ça, ça marche comme ça
:
@model = eval(“Model.#{condition}”)

Michel B.

2009/8/17 Tranquiliste [email protected]

Merci pour l’info.

Concernant le risque d’insertion du code malicieux je le gère au
niveau des named_scope avec le classique :conditions => [“champ1 = ?”,
champs1]

On 17 août, 16:13, Michel B. [email protected]

Bonjour,
J’ai lu la discussion en diagonale, Searchlogic permet l’utilisation
intuitive des named_scopes pour les recherches, ça peut t’intéresser.

2009/8/17 Tranquiliste [email protected]

Michel B. a écrit :

Disons, il va falloir faire très attention aux exploits parce que ça
veut dire donner une marge de liberté assez importante que tes
utilisateurs peuvent utiliser pour insérer potentiellement du code
malicieux ou détourner ton outil de son objectif. Mais si tu veux
faire ça, ça marche comme ça :
@model = eval(“Model.#{condition}”)
Je serais plus un send pour éviter justement les code malicieux :slight_smile:

m = Model.send(conditions.pop)
conditions.each do |c|
m = m.send(c)
end

Une question de faisabilité:
if criteria1
Merci
Nicolas


Cyril M.

Tranquiliste a écrit :

Merci pour l’info.

Concernant le risque d’insertion du code malicieux je le gère au
niveau des named_scope avec le classique :conditions => [“champ1 = ?”,
champs1]

Le code malicieux ne serait pas coté SQL, mais coté ruby exemple :

conditions => {:destroy_all}

revient à

Model.destroy_all

ca te semble sympa ?

recherche (checkbox, sélection, texte, …)
condition = condition + “.named_scope2”
end

et ainsi de suite et faire à la fin
@model = Model.condition (si oui quelle est la syntaxe?)

Merci
Nicolas


Cyril M.

Je ne dois pas tout comprendre mais je pensais faire ce qui suit et je
ne vois pas de danger
if params[:pool] == ‘1’
condition << “pool”
end
if params[:tennis] == ‘1’
condition << “tennis”
end
@locations = eval(“Location.#{condition.join(‘.’)}”)

On 17 août, 17:43, Michel B. [email protected]

Oui, je parlais bien du code ruby. Ne jamais laisser un tiers exécuter
du
code ruby arbitraire, donc faire plein de ifs c’est mieux (=
nécessaire).

Michel B.

2009/8/17 Cyril M. [email protected]

C’est ce que la gem scope-builder permet de faire :slight_smile: !
builder = Model.scope_builder

builder.named_scope_1 if xyz
builder.named_scope_2 if xyz

builder.paginate :page => params[:page]
et paf !

Ici :

Ou si vraiment c’est juste pour faire de la recherche/filtrage/ordering
SQL,
comme dis précédemment Searchlogic permet de créer des formulaires et de
réutiliser tes propres named_scope très rapidement et proprement :-).

cdt,
Nicolas (Novelys).

Le 17 août 2009 15:54, Tranquiliste [email protected] a
écrit
:

Merci à tous. En fait je ne suis pas sur d’avoir envie d’utiliser un
gem/plugin pour quelque chose qui finalement représente peu de ligne
de code (voir ci-dessous) à moins que vous me confirmiez le danger de
eval dans mon cas.

  scope = []
  scope << "in_country(#{params[:country][:id]})"
  scope << "pool" if params[:pool] == '1'
  scope << "tennis" if params[:tennis] == '1'
  scope << "close_to_sea" if params[:close_to_sea] == '1'
  scope << "handicaped" if params[:handicaped] == '1'
  scope << "pets" if params[:pets] == '1'
  scope << "smoking" if params[:smoking] == '1'
  scope << "number_of_people_greater_than(#{params

[:nb_people_from].to_i})" unless params[:nb_people_from].blank?
scope << “number_of_people_lesser_than(#{params
[:nb_people_to].to_i})” unless params[:nb_people_to].blank?
scope << “number_of_bedrooms_greater_than(#{params
[:nb_bedroom_from].to_i})” unless params[:nb_bedroom_from].blank?
scope << “number_of_bedrooms_lesser_than(#{params
[:nb_bedroom_to].to_i})” unless params[:nb_bedroom_to].blank?
@locations = eval(“Location.#{scope.join(’.’)}”)

Tranquiliste a écrit :

  scope << "handicaped" if params[:handicaped] == '1'
  @locations = eval("Location.#{scope.join('.')}")

Peu de ligne ?

Moi je trouve qu’il y en a finalement pas mal.

Ensuite comme on dit : eval c’est le mal il faut essayer de l’éviter au
maximum


Cyril M.

Une ligne par zone de recherche (plus les named_scope dans le modèle),
ce n’est quand même pas énorme?

Je comprends bien le souci du eval, mais dans mon cas, je remplis
scope et j’ai l’impression de maitriser ce qu’il y a dedans, est ce
que je me trompe?

Une ligne par named_scope, ça peut vite faire beaucoup de lignes. Ca
mériterait presque une méthode dans ton modèle pour encadrer tout ça et
nettoyer ton contrôleur.

Sinon, jusqu’Ã ce que tu oublies un “to_i” tu n’auras pas de failles
dans
l’état.

Michel B.

2009/8/18 Tranquiliste [email protected]

Donc en gros tu préfères avoir un beau bloc de 15 lignes bien moche avec
un
eval a la fin plutôt que d’utiliser une gem comme searchlogic ou
scope-builder qui te permettrait de faire ça proprement.
J’apprécie ce genre de raisonnements. Si t’utilises Rails c’est bien
pour
éviter de recréer la roue non ? Alors continue dans cette logique et
évite
ce genre de raisonnement digne d’un PHPiste-lambda dans son garage.

Nicolas (Novelys).

Le 18 août 2009 11:11, Michel B. [email protected] a
écrit :

Ouais, enfin des fois utiliser un gros gem bien lourd qui fait beaucoup
plus
que ce que tu veux faire et te complique le travail à plein de niveaux
c’est
moins pertinent que de faire une petite bidouille rapide.

Exemple : utiliser restful_authentication quand tu fais un système de
publication qui n’a qu’un utilisateur administrateur, c’est devoir te
fader
plein de complications qui ne serviront jamais à rien, même si
restful_authentication est très pertinent dès que tu as besoin d’un
système
de login où les utilisateurs s’inscrivent et confirment avec une adresse
email.

Si son truc c’est juste limité à une seule recherche dans un seul
modèle, ce
serait peut-être un peu prendre un bazooka pour tuer un moustique de
récupérer searchlogic.

Michel B.

2009/8/18 Nicolas B. [email protected]

Si son truc c’est juste limité à une seule recherche dans un seul modèle, ce
serait peut-être un peu prendre un bazooka pour tuer un moustique de
récupérer searchlogic.

C’est mon cas, une recherche sur un seul modèle.

Nicolas (Blanco), je sens comme un certain mépris dans tes propos mais
cette impression vient sans doute du côté écrit.
Rails je trouve ça très bien et j’aprécie les plugins/gems qui
existent et j’en utilise un certains nombre que je trouve
incontournables. Le défaut c’est qu’ils offrent une adhérence par
rapport aux montées de version et qu’on est pas sur qu’ils vont suivre
les évolutions de rails. Il faut donc, à mon avis, être prudent dans
ses choix ou être plus compétent que moi pour pouvoir analyser les
gems en détail.

Nicolas

Salut,

Tu devrais utiliser les anonymous scope, c’est utile dans ton cas
pour plus d’info se référer à l’épisode 112 de Railscast.

Ct ma petite contribution.

On 18 août, 07:13, Tranquiliste [email protected]