Forum: Italian Ruby user group datepicker.

B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2013-10-14 12:28
(Received via mailing list)
Salve.
Ho un problema nell'utilizzo del datepicker, che sia quello di jquery o
di
boostrap, nel locale It.
L'utente visualizza il datepicker in lingua italiana e inserendo la data
nel campo di input gli viene visualizzata nel formato dd/mm/yyy.
Rails pero' si aspetta la data nel formato yyy-mm-dd cosi' quella
inserita
dall'utente, benche' sembri funzionare perche' non risulta nessuna
eccezione, non viene memorizzata nel db.
Che soluzioni adottate in questi casi?
Dd5aabd1b5f45e007489fb0c98020a29?d=identicon&s=25 David Saitta (Guest)
on 2013-10-14 12:55
(Received via mailing list)
Ciao!

anch'io mi sono scontrato pi volte con questo problema. La soluzione
migliore secondo me  usare la gemma 'delocalize'
(https://github.com/clemens/delocalize) che ti permette di far digerire
le date con il formato del tuo locale ad AR.
Ci sono anche soluzioni legate al popolare un hidden via js con il
formato db ma mi sembra una soluzione poco solida.

ciao
David


Il giorno 14/ott/2013, alle ore 12:27, Mauro <mrsanna1@gmail.com> ha
scritto:
Ddf44bc1e0a05ca46fa9b81f1f916f15?d=identicon&s=25 Matteo Piotto (Guest)
on 2013-10-14 12:55
(Received via mailing list)
Ciao Mauro!
Una possibile soluzione, oltre ad effettuare la conversione lato ruby,
quella di usare altField del datepicker:
http://api.jqueryui.com/datepicker/#option-altField

Praticamente anzich sfruttare il datepicker direttamente sul campo
richiesto, lo usi su un campo "farlocco" mentre la data  in un campo
hidden (il field realmente letto e inviato nel form).

$( "#fakeFieldDate" ).datepicker({ altField: "#realFieldDate",
altFormat:
"yy-mm-dd", dateFormat: "dd/mm/yy"  });

In questo modo c' una divisione tra quello che  mostrato all'utente e i
valori realmente inviati all'applicazione.

Matteo
--
http://matteopiotto.com


2013/10/14 Mauro <mrsanna1@gmail.com>
F9710475ef25a597270fb24ec3298883?d=identicon&s=25 Antonio Carpentieri (Guest)
on 2013-10-14 15:19
(Received via mailing list)
Io, in un contesto di SinglePageApplication, uso moment.js[1] per
convertire in UTC prima di inviare a rails e viceversa.

A

[1] http://momentjs.com/

2013/10/14 David Saitta <david.saitta@gmail.com>
Dfa0e5f195b6f312006b465809b76b0b?d=identicon&s=25 Emanuele DelBono (Guest)
on 2013-10-14 17:59
(Received via mailing list)
Anche io come antonio uso moment.js. Ma nel tuo caso non basta settare
la
localization ad it-IT per la tua app rails? Cosi il formato gg-mm-yyyy
viene riconosciuto come data valida. Sbaglio?
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2013-10-14 19:37
(Received via mailing list)
2013/10/14 Emanuele DelBono <emanuele.delbono@gmail.com>

> Anche io come antonio uso moment.js. Ma nel tuo caso non basta settare la
> localization ad it-IT per la tua app rails? Cosi il formato gg-mm-yyyy
> viene riconosciuto come data valida. Sbaglio?
>

Dici settare il parametro config.i18n.default_locale di application.rb a
it?
Ma cosi' facendo chiudo l'app verso quel locale, se volessi usare l'app
per
utenza italiana e utenza inglese?
Magari facendo riconoscere il locale settato per il browser, non so se
questo e' possibile, ma comunque non risolve il problema del datepicker.
Avevo gia' provato a settare quel parametro in application.rb ma non mi
piace per il motivo che ti ho detto.
6aefcbf4d0ffffd2d7abdf4344cead8f?d=identicon&s=25 Sante Gennaro Rotondi (Guest)
on 2013-10-14 19:54
(Received via mailing list)
+1 per delocalize

occhio per che delocalize ha senso quando l'attributo di tipo data va a
finire in un model, altrimenti devi comunque gestire l'input ad hoc
B0f6d8efcf671ea3163449e231264cc4?d=identicon&s=25 Msan Msan (msan)
on 2013-10-14 19:58
(Received via mailing list)
2013/10/14 Sante Gennaro Rotondi <saten.r@gmail.com>

> +1 per delocalize
>
> occhio per che delocalize ha senso quando l'attributo di tipo data va a
> finire in un model, altrimenti devi comunque gestire l'input ad hoc
>

Alla fine penso che la cosa migliore e piu' semplice sia parsare l'input
sul controller prima di essere dato in pasto al db.
6aefcbf4d0ffffd2d7abdf4344cead8f?d=identicon&s=25 Sante Gennaro Rotondi (Guest)
on 2013-10-14 20:01
(Received via mailing list)
Il giorno 14/ott/2013, alle ore 19:57, Mauro <mrsanna1@gmail.com> ha
scritto:
>
> Alla fine penso che la cosa migliore e piu' semplice sia parsare l'input
> sul controller prima di essere dato in pasto al db.

Delocalize  buono perch oltre alle date si prende cura anche di
decimali, valute..

Parsare nel controller io cerco di limitarlo, anche perch devi sempre
prevedere il caso in cui ti inseriscano una data non valida e prevedere
un comportamento adeguato, ad esempio 'arrotondando' alla fine del mese
o 'sforando' nel mese successivo ;)
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.