Je suis sur que vous être déjà tombé dans le cas de figure, c’est
pourquoi je voudrais savoir comment vous vous en sortez avec.
J’ai un formulaire contenant des dates (on peut dire une déjà,
çadevrait suffire). Formulaire créé avec les helpers de rails (form_for
…) sauf pour la date car je n’aime pas le helper “datetime_select”.
Mon soucis c’est que j’aime bien utiliser ce genre de chose dans mon
controller:
def create
MonModel.new params[:monmodel]
end
Le soucis c’est que ma date arrive dans la requete HTTP au format
français: “25/09/2009” et que mon modèle ne semble pas capable de lire
cette date dans le “new”.
Comment procédez vous ?
Faut-il que je parse mes dates une par une avant de les assigner à mon
modèle ?
La dernière fois j’ai utilisé le datepicker de jquery, il permet de
définir un champ hidden avec un format au choix.
Sinon tu peut essayer delocalize :
Le 2 septembre 2009 13:48, Jean-Philippe
Moal[email protected] a écrit :
Comment procédez vous ?
Faut-il que je parse mes dates une par une avant de les assigner à mon modèle ?
La dernière fois j’ai utilisé le datepicker de jquery, il permet de
définir un champ hidden avec un format au choix.
J’avoue qu’après réfléxion, je me dit que je vais utiliser un champs
caché également. Ce qui me gène c’est le coté “je met encore du
javascript pour mettre à jour mon champ caché”…
Non, mon format est variable et dépends des clients… d’où
un
problème de format envoyé. En fait MOnObject.new params[:monobjet]
marche bien si les dates (en texte puisque venant d’une requête http)
sont aux format US (%m/%d/%Y).
Du coup je suis en train de faire un helper de date dans mon app pour
gérer un champ caché name=monobject[monattributdate] avec du
javascript pour mettre dedans une valeur format US, et ce peu importe
la locale du navigateur…
Ce qui me gène c’est l’ajout de javascript, mais j’ai l’impression de
pas pouvoir y couper… Sauf si je découpe ma date en trois champs,
comme dans les helpers de bases de rails…
français: “25/09/2009” et que mon modèle ne semble pas capable de lire
J’avoue qu’après réfléxion, je me dit que je vais utiliser un champs
caché également. Ce qui me gène c’est le coté “je met encore du
javascript pour mettre à jour mon champ caché”…
Mais par défaut, je vais faire ça.
Si tu es sûr que ton format de date est fixe tu peux faire :
class User < AR::Base
def french_date=(date)
self.my_date_field = Time.strftime(‘%d/%m/%Y’, date)
end
def french_date
Time.strptime(‘%d/%m/%Y’,self.my_date_field) # ‘12/12/2009’
end
end
et
<%= f.text_field :french_date %>
Ca marche bien aussi
PS : pas testé le strftime/strptime et la flemme de regarder la doc pour
le format exact
Le soucis c’est que ma date arrive dans la requete HTTP au format
français: “25/09/2009” et que mon modèle ne semble pas capable de lire
cette date dans le “new”.
Comment procédez vous ?
Faut-il que je parse mes dates une par une avant de les assigner à mon modèle ?
S’il s’agit juste de création d’objet tu peux peut-être overrider le
setter de la date dans ton model.
Le problème c’est que si tu as le cas dans beaucoup de modèles ça va
devenir redondant et si tu fais de la recherche par date tu retomberas
dans le même problème.
Sinon tu peux aussi faire un around_filter, tu traites tes paramètres en
entrée en regardant si tu as une date, si c’est le cas tu la transformes
en format anglais ou autre, tu yield et après tu rétablis la valeur
initiale, celle en français.
Après ça va sûrement rogner un peu sur les perfs mais faut voir dans
quelle mesure. Si c’est acceptable pour toi tu peux le mettre sur le
application_controller et tu ne seras plus embêté.
Quand tu dis “un format variable”, tu veux dire que ton application
est localisée ? Si c’est le cas, quel système utilises-tu pour la
localisation ?
Effectivement, c’est localisé. Et j’avoue que j’ai pas forcement
épluché plusieurs solution de localisation, j’utilise le truc fourni
avec Rails (enfin je crois). L’histoire des fichiers dans le rep
config/locales/en.yml et toutiquanti…
Il existe des solution meilleurs ?
ps: J’ai fait un essaie rapide avec le code que propose Alexis, et
çasemble marcher… Il faut que j’étofe ma couverture de test sur ces
cas.
Note : l’emploi de JavaScript est sensé être pour le confort de
l’internaute. Un formulaire devrait pouvoir fonctionner sans.
Je suis entierement d’accord ! Mais malheureusement, le client chez
qui je suis ne veut pas l’entendre de cette manière. Heureusement,
c’est une appli de gestion interne sur un parc matériel presque
maitrisé, donc je ferme les yeux avec regret…
Non, mon format est variable et dépends des clients… d’où un
problème de format envoyé. En fait MOnObject.new params[:monobjet]
marche bien si les dates (en texte puisque venant d’une requête http)
sont aux format US (%m/%d/%Y).
Bonjour Yannick,
Quand tu dis “un format variable”, tu veux dire que ton application
est localisée ? Si c’est le cas, quel système utilises-tu pour la
localisation ?
Note : l’emploi de JavaScript est sensé être pour le confort de
l’internaute. Un formulaire devrait pouvoir fonctionner sans.
Je ne trouve pas très élégant la solution JS lorsqu’on a tout pour faire de
la localisation en Rails.
J’utilise le code que je t’ai fillé depuis quelques temps pour une appli et
depuis les dates passent comme une lettre à la Poste
En fait quand je parlait de JS, c’est l’utilisation de datepicker et
autres jquery… Je souhaite ne pas à avoir à parser les dates en js
pour le formatter pour rails… D’où mon mail et d’où le fait que je
suis en train de mettre ta solution en place :-p
Effectivement, c’est localisé. Et j’avoue que j’ai pas forcement
épluché plusieurs solution de localisation, j’utilise le truc fourni
avec Rails (enfin je crois). L’histoire des fichiers dans le rep
config/locales/en.yml et toutiquanti…
Il existe des solution meilleurs ?
Il s’agit de l’API i18n parue avec Rails 2.2. Et comme c’est standard,
autant l’utiliser !
ps: J’ai fait un essaie rapide avec le code que propose Alexis, et ça
semble marcher… Il faut que j’étofe ma couverture de test sur ces
cas.
La propostion d’Alexis est plus jolie que ce que j’utilise, mais
l’idée est la même. Je voulais juste être sûr que ça correspondait à
tes besoins.
Bonne continuation !
–
Julien Vignolles
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
