Page cache e query string in Rails


#1

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


#2

— Massimiliano M. removed_email_address@domain.invalid 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


#3

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 :wink: (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