Forum: Italian Ruby user group Page cache e query string in Rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
30cb10b258fc90a05e97d63380133bf0?d=identicon&s=25 Massimiliano Mirra (Guest)
on 2006-04-11 00:51
(Received via mailing list)
Prima che mi tiri la zappa sui piedi mettendo quanto segue in
produzione, qualcuno con esperienza con il page cache in Rails può
dirmi se c'è una trappola?

Leggevo che uno dei problemi del page cache è la query string.  Una
richiesta come /article/list?page=1 verrebbe messa in cache come
/article/list.html, e le successive richieste ad /article/list?page=2,
/article/list?page=3 restituirebbero sempre /article/list.html.

Ora, ho mezzo risolto facendo riscrivere a lighttpd
/article/list?page=1 in /article/list/query/page=1 prima di passarlo a
Rails (mezzo risolto nel senso che non ho ancora affrontato la
riscrittura in lighttpd, ma il resto funziona).  Nelle routes di
Rails, ho qualcosa come:

  map.connect('article/list/query/:query_string',
    :controller => 'article',
    :action => 'list')

In un before_filter integro params[:query_string] col resto di params
e la vita procede come al solito.  Poi, quando viene richiesta
/article/list?page=1, Rails genera /article/list/query/page=1.html;
quando viene richiesta /article/list?page=2, Rails genera
/article/list/query/page=2.html, e così via.  Alla seconda richiesta,
queste pagine vengono servite staticamente.

Mi pare abbastanza banale, ma scorrazzando in giro per la rete non ho
visto usare questo approccio.  Dov'è la trappola?


Massimiliano

--
blog: http://blog.hyperstruct.net
sw: http://dev.hyperstruct.net, http://repo.hyperstruct.net
C01072ccffb1f2d23f8b5f686e5b106a?d=identicon&s=25 gabriele renzi (Guest)
on 2006-04-11 06:25
(Received via mailing list)
--- Massimiliano Mirra <i81rnqg02@sneakemail.com> ha
scritto:

> /article/list?page=2,
> /article/list?page=3 restituirebbero sempre
> /article/list.html.
>
> Ora, ho mezzo risolto facendo riscrivere a lighttpd
> /article/list?page=1 in /article/list/query/page=1
> prima di passarlo a
> Rails (mezzo risolto nel senso che non ho ancora
> affrontato la
> riscrittura in lighttpd, ma il resto funziona).

perché non usi la cosa classica
 /article/list/page/2
o magari, contaendola eliminando "page" ed altre cose
in mezzo, che ne so per
 /article/id/1234/page/2
direttamente
 /article/1234/2

?



--
icq:  #69488917
blog: http://riffraff.blogsome.com






___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
30cb10b258fc90a05e97d63380133bf0?d=identicon&s=25 Massimiliano Mirra (Guest)
on 2006-04-11 13:26
(Received via mailing list)
> perché non usi la cosa classica
>  /article/list/page/2
> o magari, contaendola eliminando "page" ed altre cose
> in mezzo, che ne so per
>  /article/id/1234/page/2
> direttamente
>  /article/1234/2
>
> ?

Per tenere separate le risorse ben definite e univocamente
identificate nel corso del tempo (/article/1234) dalle variazioni di
presentazione su un'aggregazione mutevole (?page=2) o su una risorsa
stessa (?layout=tabular, etc.), e perché il path info, anche se più
leggibile di una query string, dà meno libertà: /t/1/c/2 non è lo
stesso di /c/2/t/1 mentre ?t=1&c=2 e ?c=2&t=1 lo sono.  Cerco insomma
di legarmi a una rappresentazione rigida solo per le componenti
fondamentali e meno suscettibili di miei cambiamenti d'umore di qui a
sei ore ;-) (di legarsi si tratta, quando l'alternativa è spezzare i
link che puntano a te o un'API che conta su una certa interfaccia).


--
blog: http://blog.hyperstruct.net
sw: http://dev.hyperstruct.net, http://repo.hyperstruct.net
This topic is locked and can not be replied to.