Rails, link_to, mootools e l'unobstrusive javascript

#1

Ciao! Ho 2 problemi: uso mootools (http://www.mootools.net), e come se
non bastasse, adoro l’unobstrusive javascript…

Sto cominciando ad usare Rails, ma di mio sono un web-designer e
programmatore client-side, esperto in ActionScript e JavaScript. In
particolare, dopo aver usato a lungo prototype+scriptaculous, sono
passato a mootools 1.2b2, perché secondo me al momento è nettamente
superiore per tutta una serie di fattori che non sto qua a discutere.

Ora, Rails fa 2 cose che non mi piacciono:

  1. Piazza continuamente eventi nei tag (es.
    ecc), quando ormai lo stile di programmazione javascript sta andando
    sempre + dalla parte opposta. E io pure. C’è un modo per evitarlo?

  2. Rails lavora con prototype+scriptaculous. E io no. Ora, non chiedo
    molto, non mi interessa avere un’integrazione vera e propria di
    mootools, perché mi arrangio a farmi i miei js. Solo vorrei un modo per
    usare Rails senza che, ad es., mi piazzasse automaticamente nei link
    generati in alcuni casi da link_to, delle funzioni proprietarie di
    prototype o scriptaculous. Si può? Qualcuno sa come fare?

#2

Luca R. ha scritto:

  1. Rails lavora con prototype+scriptaculous. E io no. Ora, non chiedo
    molto, non mi interessa avere un’integrazione vera e propria di
    mootools, perché mi arrangio a farmi i miei js. Solo vorrei un modo per
    usare Rails senza che, ad es., mi piazzasse automaticamente nei link
    generati in alcuni casi da link_to, delle funzioni proprietarie di
    prototype o scriptaculous. Si può? Qualcuno sa come fare?

Di default se non gli dici esplicitamente di fare cose strane link_to
non usa helper javascript. Se usi link_to_remote lo fa, ma
link_to_remote è possibile solo in virtù dell’integrazione con prototype.

Puoi tranquillamente codificare la tua app senza javascript ed
aggiungere il supporto js tutto esternamente con il tuo framework js di
fiducia.

#3

Mah, guarda, sto studiando “the rails way”, e nel capitolo dedicato a
REST, parlando di destroy, porta l’esempio di un link di questo tipo:

<%= link_to(“delete”, user_path(user), :method => delete) if
current_user.admin? %>

il quale genera un disastro di javascript infarcito di metodi di
prototype come createElement o setAttribute, piazzato nell’onclick. :frowning:

Buuu… Vabbé, controlli di quel genere si possono immagino spostare nel
controller…

Anyway, grazie e buona giornata.

Giovanni I. wrote:

Luca R. ha scritto:

  1. Rails lavora con prototype+scriptaculous. E io no. Ora, non chiedo
    molto, non mi interessa avere un’integrazione vera e propria di
    mootools, perch� mi arrangio a farmi i miei js. Solo vorrei un modo per
    usare Rails senza che, ad es., mi piazzasse automaticamente nei link
    generati in alcuni casi da link_to, delle funzioni proprietarie di
    prototype o scriptaculous. Si pu�? Qualcuno sa come fare?

Di default se non gli dici esplicitamente di fare cose strane link_to
non usa helper javascript. Se usi link_to_remote lo fa, ma
link_to_remote � possibile solo in virt� dell’integrazione con prototype.

Puoi tranquillamente codificare la tua app senza javascript ed
aggiungere il supporto js tutto esternamente con il tuo framework js di
fiducia.

#4

2008/3/3 Luca R. removed_email_address@domain.invalid:

Mah, guarda, sto studiando “the rails way”, e nel capitolo dedicato a
REST, parlando di destroy, porta l’esempio di un link di questo tipo:

<%= link_to(“delete”, user_path(user), :method => delete) if
current_user.admin? %>

l’obiettivo di quel codice e’ di generare (dinamicamente) una form
nascosta
che faccia il post all’url indicata nel link aggiungendo il parametro
_method con valore “delete” che serve come “trucco” per aggirare il
fatto
che il browser NON supporta altro che POST o GET mentre la richiesta
corretta HTTP sarebbe stata una DELETE.

purtroppo se non vuoi scrivere una form (o almeno un bottone) per ogni
comando che inserisci nell’interfaccia che fa delete (o update) su un
servizio rails sviluppato come REST-ful, ma vuoi usare un link devi in
qualche modo usare javascript per trasformare il click in un post.

Gli helper javascript di rails, per ogni uso di javascript, sono legati
a
filo doppio a protoype e scriptaculous essendo quelle le librerie di js
che
fanno parte della distribuzione del framework, nel tuo caso quello che
vuoi
fare non lo devi fare usando il :method=>delete ma agganciando in modo
unbotrusive i link che ti interessano e generando la form con mootools.

Pero’ mi pare che esistano anche plugins che modificano il comportamento
standard degli helper di rails per supportare altre librerie javascript,
ma
non ne ho usato nessuno…

HTH, ciao,
Luca M.

#5

Ah ho capito… Pensa che pensavo dipendesse sopratuttto dall’ “if
current_user.admin?” più che da delete… In effetti allora posso evitare
il delete e sostituire il codice che genera con mootools…
GRAZIE! :slight_smile:

Luca M. wrote:

2008/3/3 Luca R. removed_email_address@domain.invalid:

Mah, guarda, sto studiando “the rails way”, e nel capitolo dedicato a
REST, parlando di destroy, porta l’esempio di un link di questo tipo:

<%= link_to(“delete”, user_path(user), :method => delete) if
current_user.admin? %>

l’obiettivo di quel codice e’ di generare (dinamicamente) una form
nascosta
che faccia il post all’url indicata nel link aggiungendo il parametro
_method con valore “delete” che serve come “trucco” per aggirare il
fatto
che il browser NON supporta altro che POST o GET mentre la richiesta
corretta HTTP sarebbe stata una DELETE.

purtroppo se non vuoi scrivere una form (o almeno un bottone) per ogni
comando che inserisci nell’interfaccia che fa delete (o update) su un
servizio rails sviluppato come REST-ful, ma vuoi usare un link devi in
qualche modo usare javascript per trasformare il click in un post.

Gli helper javascript di rails, per ogni uso di javascript, sono legati
a
filo doppio a protoype e scriptaculous essendo quelle le librerie di js
che
fanno parte della distribuzione del framework, nel tuo caso quello che
vuoi
fare non lo devi fare usando il :method=>delete ma agganciando in modo
unbotrusive i link che ti interessano e generando la form con mootools.

Pero’ mi pare che esistano anche plugins che modificano il comportamento
standard degli helper di rails per supportare altre librerie javascript,
ma
non ne ho usato nessuno…

HTH, ciao,
Luca M.

#6

Il giorno 03/mar/08, alle ore 15:35, Luca R. ha scritto:

<%= link_to(“delete”, user_path(user), :method => delete) if
current_user.admin? %>

il quale genera un disastro di javascript infarcito di metodi di
prototype come createElement o setAttribute, piazzato nell’onclick. :frowning:

Non sono metodi prototype, sono metodi standard del dom. In effetti
dimenticavo il caso in cui hai bisogno di verbi http non POST/GET
(quindi EDIT e DELETE). Per questo tipo di link viene generato del
javascript liscio (non prototype) in supporto dell’approccio RESTFUL.

#7

Hai ragione, è javascript normale, pardon… Rimane comunque il problema
dell’unobstrusive javascript, per il quale è auspicabile usare prototype
o mootools, nel mio caso mootools, ma in effetti Luca M. ha dato
un buon suggerimento in merito.

Grazie ancora comunque! :slight_smile:

Giovanni I. wrote:

Il giorno 03/mar/08, alle ore 15:35, Luca R. ha scritto:

<%= link_to(“delete”, user_path(user), :method => delete) if
current_user.admin? %>

il quale genera un disastro di javascript infarcito di metodi di
prototype come createElement o setAttribute, piazzato nell’onclick. :frowning:

Non sono metodi prototype, sono metodi standard del dom. In effetti
dimenticavo il caso in cui hai bisogno di verbi http non POST/GET
(quindi EDIT e DELETE). Per questo tipo di link viene generato del
javascript liscio (non prototype) in supporto dell’approccio RESTFUL.

#8

2008/3/3 Giovanni I. removed_email_address@domain.invalid:

Per questo tipo di link viene generato del
javascript liscio (non prototype) in supporto dell’approccio RESTFUL.

mi sa che hai ragione… andavo a memoria :frowning: e mi pareva usasse js da
prototype (ma e’ molto piu ragionevole che non lo faccia in questi casi)

bye
Luca

#9

tra i miei link ho questo: http://code.google.com/p/mootools-on-rails/
oppure leggi le ultime righe della sezione “Contact” di
http://ennerchi.com/projects/jrails

nb non uso mootools

Luca R. ha detto: in data 3/3/2008 15:18:

#10

bhe se gli helper di base che ti fornisce non ti piacciono puoi sempre
generartene tuoi ad hoc che usino altre librerie al posto di prototype o
anche niente js …

#11

Luca R. wrote:

Ah ho capito… Pensa che pensavo dipendesse sopratuttto dall’ “if
current_user.admin?” più che da delete… In effetti allora posso evitare
il delete e sostituire il codice che genera con mootools…
GRAZIE! :slight_smile:

Luca,

di fatto Rails è legato a doppio filo con Prototype e riscriversi degli
helper per un’altra libreria vanifica molto del tempo che si risparmia
usando Rails al posto di altri framework. Tuttavia se fai qualcosa di
interessante con mootools ricordati di postarci qualcosa. In
particolare, sarebbe bello mantenere la stessa API di quelli Prototype,
per poter slegare le nostre applicazioni dalla libreria Javascript e
migrarle a nuove mano a mano che i benchmark o il supporto lo
consigliano.

Soprattutto, tienici informati dei tuoi progressi

Paolo

#12

On Mar 10, 2008, at 3:14 PM, Paolo M. wrote:

Luca,

di fatto Rails è legato a doppio filo con Prototype

Non e’ del tutto vero, tant’e’ c’e’ chi ha scritto un plugin per
rimpiazzare completamente Prototype
con jQuery in modo del tutto trasparente (comperso il supporto per i
template RJS):

http://ennerchi.com/projects/jrails

Per quanto mi riguarda, evito accuratamente di appoggiarmi agli helper
per generare javascript
all’interno delle pagine. Piuttosto, genero un html assolutamente
“stupido”, poi aggiungo i comportamenti
dinamici con LowPro:

http://www.danwebb.net/2006/9/3/low-pro-unobtrusive-scripting-for-prototype

e mi appoggio agli helper solo per generare il codice delle risposte
AJAX.

S.

#13

Ciao Paolo,

ok vi terrò informati :wink:

Il problema è che dopo + di un anno di utilizzo di prototype e
scriptaculous, scrivendo svariate classi eccetera, ho scoperto che
scriptaculous semplicemente non riesce a gestire gli effetti come si
deve (e poi pesa, e poi ha altri problemi, e poi…). In altre parole,
con scriptaculous NON si posso fare certe cose, che invece faccio con
mootools, che in origine era nato proprio come risposta ai suddetti
problemi. Purtroppo le 2 librerie non sono compatibili, non posso tenere
nella stessa pagina mootools e prototype, dunque al momento devo
rinunciare ai precotti di Rails.

Luca

Paolo M. wrote:

Luca R. wrote:

Ah ho capito… Pensa che pensavo dipendesse sopratuttto dall’ “if
current_user.admin?” più che da delete… In effetti allora posso evitare
il delete e sostituire il codice che genera con mootools…
GRAZIE! :slight_smile:

Luca,

di fatto Rails è legato a doppio filo con Prototype e riscriversi degli
helper per un’altra libreria vanifica molto del tempo che si risparmia
usando Rails al posto di altri framework. Tuttavia se fai qualcosa di
interessante con mootools ricordati di postarci qualcosa. In
particolare, sarebbe bello mantenere la stessa API di quelli Prototype,
per poter slegare le nostre applicazioni dalla libreria Javascript e
migrarle a nuove mano a mano che i benchmark o il supporto lo
consigliano.

Soprattutto, tienici informati dei tuoi progressi

Paolo

#14

Io ho provato ad adattarmi a prototype, volevo farlo per sfruttare gli
helper ma soprattutto per rimanere nello standard, il bello di rails è
anche questo.
Nell’adattamento della mia piccola applicazione di prova a prototype
però sono rimasto un pò deluso, forse per l’abitudine ma mi sono accorto
di quanto è comodo ed efficace jquery: selezione degli elementi con un
unico metodo e sfruttando il css 3 (prototype ne ha uno per l’id ed uno
per il css), il concatenamento per svolgere molteplici operazioni su una
sola riga (stile ruby) mentre con prototype non è possibile, un solo
file .js, effetti base già inclusi e molto efficaci.
Jrails non l’ho mai usato …non mi piace l’idea di dipendere da delle
“traduzioni”/“adattamenti”, però in futuro chissÃ

#15

Tkz Tud!

Tud wrote:

tra i miei link ho questo: http://code.google.com/p/mootools-on-rails/
oppure leggi le ultime righe della sezione “Contact” di
http://ennerchi.com/projects/jrails

nb non uso mootools

Luca R. ha detto: in data 3/3/2008 15:18:

#16

Ciao Marco,

guarda comunque che le cose che dici le puoi fare anche con prototype,
almeno con l’ultima versione.

Ma ormai si possono fare con tutti i framework, mootools 1.2b2 compreso.
La forza di mootools sta nella gestione degli effetti, soprattutto di
chiamate multiple dello stesso effetto sullo stesso oggetto, che in
scriptaculous causa un crash, ed è il motivo principale per cui ho
cambiato barca :slight_smile:

Poi se ti può interessare la beta è estremamente efficace anche nella
gestione degli eventi e degli stili, ha parecchi plugin interessanti, e
come jQuery la scarichi in un solo file, scegliendo però selettivamente
i componenti da includere (!) e fra 4 diversi livelli di compressione
(!!):

http://mootools.net/download/tags/1-2b2

NOTA: non è per dire che questo è meglio di quello, non m’interessa…
Semplicemente volevo passarti la dritta, che magari ti può tornare
utile.

Hola!

Marco M. wrote:

Io ho provato ad adattarmi a prototype, volevo farlo per sfruttare gli
helper ma soprattutto per rimanere nello standard, il bello di rails è
anche questo.
Nell’adattamento della mia piccola applicazione di prova a prototype
però sono rimasto un pò deluso, forse per l’abitudine ma mi sono accorto
di quanto è comodo ed efficace jquery: selezione degli elementi con un
unico metodo e sfruttando il css 3 (prototype ne ha uno per l’id ed uno
per il css), il concatenamento per svolgere molteplici operazioni su una
sola riga (stile ruby) mentre con prototype non è possibile, un solo
file .js, effetti base già inclusi e molto efficaci.
Jrails non l’ho mai usato …non mi piace l’idea di dipendere da delle
“traduzioni”/“adattamenti”, però in futuro chissÃ

#17

On Wed, Mar 12, 2008 at 9:58 AM, Marco M. <
removed_email_address@domain.invalid> wrote:

Io ho provato ad adattarmi a prototype, volevo farlo per sfruttare gli
helper ma soprattutto per rimanere nello standard, il bello di rails è
anche questo.
Nell’adattamento della mia piccola applicazione di prova a prototype
però sono rimasto un pò deluso, forse per l’abitudine ma mi sono accorto
di quanto è comodo ed efficace jquery: selezione degli elementi con un
unico metodo e sfruttando il css 3 (prototype ne ha uno per l’id ed uno
per il css),

il concatenamento per svolgere molteplici operazioni su una

sola riga (stile ruby) mentre con prototype non è possibile, un solo

Teoricamente prototype dalla versione 1.5.1 dovrebbe supportare CSS3
tranne
gli pseudo-elementi (::first-letter) e le pseudo-classi (:hover).
Inoltre la maggior parte dei metodi di Element ritornano l’elemento
stesso,
quindi puoi fare cose del tipo:

$(‘message’).addClassName(‘read’).update(‘I read this
message!’).setStyle({opacity: 0.5}); // preso dal sito di prototype JS

#18

Avete ragione l’ultima versione di prototype, la 1.6.2 che sto provando
ora supporta le funzioni a cascata (e forse anche la 1.5.0, sbagliavo
qualcosa io?) però, solo curiosità , non capisco perchè avere un doppio
selettore $ e il $$ per il css, tra l’altro questo restituisce un array
e bisogna ciclare tra gli elementi, mentre con jquery facendo esempio:
$(‘h2’).show(‘slow’).text(‘bla bla bla bla’)
applica dall’ultima funzione alla prima su tutto l’array degli elementi,
o si può fare un qualcosa del genere con prototype?

Trovo anche un pò scomodo l’utilizzo di scrip.aculo.us, con la necessitÃ
di inserire il costruttore, esempio:
onclick=“new Effect.toggle(‘attachment_new’,‘appear’); return false;”
non si possono usare le cascate anche per gli effetti? Io non ci sono
riuscito

Poi altra cosa: solitamente utilizzo una classe “.hidden” per nascondere
gli elementi… prototype (come anche jquery) utilizza gli style (per
prevalere su eventuali classi) ma facendo una show di un mio elemento
.hidden non lo mostra perchè lo show toglie (se c’è) il display:none
dallo style, mentre jquery fa un display: block, riuscendo così a
mostrare il contenuto

Non so forse sono prevenuto oppure jquery è fatto su misura per me. Ci
mancherebbe, continuo ad usarlo su rails però…

#19

On Mar 12, 2008, at 4:51 PM, Marco M. wrote:

o si può fare un qualcosa del genere con prototype?
$$(‘h2’).invoke(‘show’, ‘slow’).invoke(‘text’, ‘bla bla bla’)

S.

#20

Marco M. wrote:

Avete ragione l’ultima versione di prototype, la 1.6.2 che sto provando
ora supporta le funzioni a cascata (e forse anche la 1.5.0, sbagliavo
qualcosa io?) però, solo curiosità , non capisco perchè avere un doppio
selettore $ e il $$ per il css, tra l’altro questo restituisce un array
e bisogna ciclare tra gli elementi, mentre con jquery facendo esempio:
$(‘h2’).show(‘slow’).text(‘bla bla bla bla’)
applica dall’ultima funzione alla prima su tutto l’array degli elementi,
o si può fare un qualcosa del genere con prototype?

Con prototype non ricordo, con mootools il doppio $$ serve, tra le altre
cose, per usare un metodo su tutti gli elementi di una collezione (di
qualunque tipo) in un’unica istruzione. Es. supponiamo una collezione di
link:

$$(this.mainButtons).addEvents({
‘click’:function(){…}.bindWithEvent(this),
‘mouseover’:function(){…}.bindWithEvent(this),
ecc…
})

Assegno tutti gli eventi a tutti i pulsanti con addEvents();

oppure es.

$$(collezione).setStyles{‘opacity’:0.5, ‘color’:’#ff0000’}

Trovo anche un pò scomodo l’utilizzo di scrip.aculo.us, con la necessitÃ
di inserire il costruttore, esempio:
onclick=“new Effect.toggle(‘attachment_new’,‘appear’); return false;”
non si possono usare le cascate anche per gli effetti? Io non ci sono
riuscito

Come ho detto, scriptaculous con gli effetti è un disastro. Guarda qua,
quando parla della link option:

http://blog.mootools.net/2007/10/23/The_Best_Javascript_Effects_Now_Even_Better

Poi altra cosa: solitamente utilizzo una classe “.hidden” per nascondere
gli elementi… prototype (come anche jquery) utilizza gli style (per
prevalere su eventuali classi) ma facendo una show di un mio elemento
.hidden non lo mostra perchè lo show toglie (se c’è) il display:none
dallo style, mentre jquery fa un display: block, riuscendo così a
mostrare il contenuto

Credo che con prototype si possano assegnare anche classi. Con mootools
puoi assegnare, aggiungere, togliere, addirittura fare un toggle, e in
diversi modi (addClass, removeClass, toggleClass, ma soprattutto set!):

http://docs12b.mootools.net/Element/Element

Hola!