Forum: Italian Ruby user group array come parametro

In una vista devo passare un array come parametro:
<%= link_to "bla", { :controller=>"contr", :action=>"no_mapp", :righe =>
@righe } %>

@righe è un array che se è grande genera il seguente errore:
RequestURITooLarge

Come posso fare?

Grazie per le eventuali risposte

probabile che l'arai contenga troppi elementi, superando il limite di 
lunghezza. questa risposta su stackoverflow  pi completa della mia ;)

http://stackoverflow.com/questions/417142/what-is-...

A. (proudly from Rails Rumble 2012)


Il giorno 13/ott/2012, alle ore 19:57, Mariarosaria Trovato 
<mrtvt@libero.it> ha scritto:

>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml

--
http://andreapavoni.com

Comprimi l'array in qualche modo prima di passarlo nella querystring.
Oppure salvati l'array nel database e passa il riferimento del record 
nella querystring.

-f

Andrea Pavoni wrote in post #1079734:
> probabile che l'arai contenga troppi elementi, superando il limite di

Questo lo so.
*@righe è un array che se è grande genera il seguente errore:
RequestURITooLarge* l'ho indicato per chiarezza.
In ogni caso ho risolto definendo un metodo
  def no_mapp
    @righe = @@righe_no_mapp
  end
Ma la domanda è per trovare una soluzione 'elegante' al problema,
per esempio mi viene in mente il passaggio del puntatore all'array
(come per il c ma non per ruby).
Spero di essere stata chiara.
Grazie

2012/10/14 Mariarosaria Trovato <mrtvt@libero.it>:


> Ma la domanda  per trovare una soluzione 'elegante' al problema,
> per esempio mi viene in mente il passaggio del puntatore all'array
> (come per il c ma non per ruby).


usa una POST invece di una GET (non mi ricordo se esiste ancora
l'helper "button_to" ma son 5 righe di codice a riscriverlo)



--
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

Sarebbe utile se fornissi un contesto pi ampio. Ragionando in termini di
risorse, qual il caso che ti porta a richiamarne una identificata da un
array?
Il giorno 14/ott/2012 08:57, "Mariarosaria Trovato" <mrtvt@libero.it> ha
scritto:

+1 per usare una POST
Su rails 3 basta aggiungere method: :post ai parametri per link_to e 
viene
automaticamente generata e submittata la form quando clicchi sul link.
In pi non devi preoccuparti della sessione

Sent from mobile device.
Il giorno 14/ott/2012 09:26, "gabriele renzi" <rff.rff@gmail.com> ha
scritto:

Il giorno 14/ott/2012, alle ore 08:57, Mariarosaria Trovato 
<mrtvt@libero.it> ha scritto:

> Andrea Pavoni wrote in post #1079734:
>> probabile che l'arai contenga troppi elementi, superando il limite di
> In ogni caso ho risolto definendo un metodo
>  def no_mapp
>    @righe = @@righe_no_mapp
>  end

mi sto perdendo il contesto. cosa  quel pezzo di codice? dove s trova?

cosa dovrebbe fare?

> Ma la domanda  per trovare una soluzione 'elegante' al problema,
> per esempio mi viene in mente il passaggio del puntatore all'array
> (come per il c ma non per ruby).

vuoi usare un puntatore per un link http? :-O


--
http://andreapavoni.com

> mi sto perdendo il contesto. cosa  quel pezzo di codice? dove s trova?
>
> cosa dovrebbe fare?
Ho sostituito

<%= link_to "bla", { :controller=>"contr", :action=>"no_mapp", :righe =>
@righe } %>
con

<%= link_to "righe non_mappate", { :controller=>"spring", 
:action=>"no_mapp"} %>
con
def no_mapp
    @righe = @@righe_no_mapp
  end
era solo per dire che una soluzione l'ho trovata.
E la possiamo dimenticare.
Il punto è: come faccio a passare un array(grande) come parametro?
Citavo il puntatore per dire che se si potesse passerei semplicemente il 
puntatore all'array righe.
Ciao

> Il punto è: come faccio a passare un array(grande) come parametro?

Rilancio il suggerimento di Sante di usare :method => :post
La tua

<%= link_to "bla", { :controller=>"contr", :action=>"no_mapp", :righe =>
@righe } %>

diventa

<%= link_to "bla", { :controller=>"contr", :action=>"no_mapp", :righe =>
@righe, :method => :post } %>

Cito dalla documentazione

:method => symbol of HTTP verb - This modifier will dynamically create
an HTML form and immediately submit the form for processing using the
HTTP verb specified. Useful for having links perform a POST operation in
dangerous actions like deleting a record (which search bots can follow
while spidering your site). Supported verbs are :post, :delete and :put.
Note that if the user has JavaScript disabled, the request will fall
back to using GET. If :href => '#' is used and the user has JavaScript
disabled clicking the link will have no effect. If you are relying on
the POST behavior, you should check for it in your controller’s action
by using the request object’s methods for post?, delete? or put?.

Paolo

Ho usato :method => :post anche se non lo ho indicato nell'esempio ma il 
problema permane.
Mi rendo conto che l'errore RequestURITooLarge è fuorviante quindi mi 
chiarisco con un esempio.
Supponiamo che nel controller ho una certa azione

def una_azione
 @righe = Array.new
## costruisco in qualche modo un array di hash @righe con anche elementi 
duplicati
 @u_righe = @righe.clone
 @u_righe.uniq!
# ho quindi questi due array
end

nella vista una_azione ho
<% for riga in @righe %>
# visualizza l'array di hash
<% end %>
e ho qui un link ad una vista diciamo u_vista
in cui voglio visualizzare @u_array
senza usare come ho fatto
  def u_vista
    @righe = @@u_righe
  end
trasformando @u_righe i @@u_righe nella azione una_azione

Spero di essere stata chiara
Grazie a tutti

Alla fine va bene tutto, per non userei un POST solo perch la URL 
troppo lunga. C' qualcosa di sbagliato.
Ci sono delle controindicazioni nell'uso della POST, ad esempio 
l'impossibilit di ricaricare la pagina di destinazione senza inviare 
nuovamente il form. Ovvero ti perdi l'indirizzabilit della risorsa, che 
ha un gran valore.

-f

Il giorno 14/ott/2012, alle ore 16:36, Fabrizio Regini 
<freegenie@gmail.com> ha scritto:

> Alla fine va bene tutto, per non userei un POST solo perch la URL  troppo lunga. 
C' qualcosa di sbagliato.
> Ci sono delle controindicazioni nell'uso della POST, ad esempio l'impossibilit 
di ricaricare la pagina di destinazione senza inviare nuovamente il form. Ovvero 
ti perdi l'indirizzabilit della risorsa, che ha un gran valore.


+1

come side note, ho il sospetto che ci sia qualcosa di errato 
nell'approccio se hai bisogno di sparare un mega-array di parametri. si 
potrebbe considerare di poggiarli momentaneamente su db, e recuperarli 
tramite una chiave.


A.
--
http://andreapavoni.com

> come side note, ho il sospetto che ci sia qualcosa di errato
> nell'approccio se hai bisogno di sparare un mega-array di parametri. si
> potrebbe considerare di poggiarli momentaneamente su db, e recuperarli
> tramite una chiave.

Non è necessario arrivare a tanto.
Come vedi dall'esempio ho risolto con una variabile di classe
trasformando @u_righe i @@u_righe nella prima azione
Cercavo un modo di passare come parametro non l'array ma qualcosa che
me lo potesse poi far recuperare (tipo puntatore del c).

Presumo tu stia iniziando a studiare Ruby oppure Rails, continua cos, 
non mollare!

Quello che dici, ovvero usare la memoria del processo per la persistenza 
dei dati,  una soluzione che in un ambiente i produzione non molto 
praticata. Per questo alcuni di noi, me compreso, non capivano la 
domanda.

Quello che dici te :

- Ho un controller con due azioni: in una setto un array come variabile 
di classe del controller, nell'altra leggo quell'array.

Una delle ragioni per cui non si fa  che il processo della tua 
applicazione pu ricevere, tra la tua prima richiesta e la seconda, la 
prima richiesta di un altro utente, che pu cambiare quel valore.

Se si tratta di un valore globale questo pu non essere un problema. Ad 
ogni modo in questo caso si parla cache. Rails dispone di API per la 
gestione della cache:

http://guides.rubyonrails.org/caching_with_rails.html

E' possibile configurare Rails per usare backend diversi per il caching 
e, tra questi, guarda caso, c' anche il memory_store, che fa quello che 
abbiamo detto pocanzi, ovvero usa la memoria del processo per mantenere 
il valori tra le richieste.

Ti consiglio per cose del genere di prendere in considerazione anche una 
variabile di sessione.

-f

Si deve fare attenzione ad usare la sessione per dati grossi perché per
default la sessione è memorizzata nei cookie. Oltre un certo limite si
deve cambiare il SessionStore. Tuttavia c'è davvero qualcosa che non va
in quest'approccio: mandare i dati avanti e indietro per la rete è
sicuramente meno efficiente che memorizzarli sul server.

Se ci pensate, il luogo naturale per memorizzare grandi quantità di dati
è il database del server o il suo file system. Memorizzando lì dentro
@@u_righe poi si riesce a far viaggiare in rete solo un id numerico
dentro a delle GET. E' quello che si fa tutto il tempo con i metodi REST
dei controller Rails. Perché cambiare?

Quando anni fa passai da Struts (Java) a Rails mettevo anch'io tanti
dati in sessione. Poi dopo aver scritto un session store che si
appoggiava al database mi resi conto che era inutile: tanto vale avere
delle tabelle con cui memorizzare quel che serve ed usare un id per
farvi riferimento. Attenzione ad avere lo user_id nella tabella, ed
usarlo per i controlli sull'accesso.

A proposito, usando @@u_righe si deve pensare ad un modo per impedire ad
utenti diversi del sistema a non pasticciarsi i dati l'uno con l'altro.

Paolo



Fabrizio Regini wrote in post #1079812:
> Presumo tu stia iniziando a studiare Ruby oppure Rails, continua cos,
> non mollare!
>
> Quello che dici, ovvero usare la memoria del processo per la persistenza
> dei dati,  una soluzione che in un ambie nte i produzione non molto
> praticata. Per questo alcuni di noi, me compreso, non capivano la
> domanda.
>
> Quello che dici te :
>
> - Ho un controller con due azioni: in una setto un array come variabile
> di classe del controller, nell'altra leggo quell'array.
>
> Una delle ragioni per cui non si fa  che il processo della tua
> applicazione pu ricevere, tra la tua prima richiesta e la seconda, la
> prima richiesta di un altro utente, che pu cambiare quel valore.
>
> Se si tratta di un valore globale questo pu non essere un problema. Ad
> ogni modo in questo caso si parla cache. Rails dispone di API per la
> gestione della cache:
>
> http://guides.rubyonrails.org/caching_with_rails.html
>
> E' possibile configurare Rails per usare backend diversi per il caching
> e, tra questi, guarda caso, c' anche il memory_store, che fa quello che
> abbiamo detto pocanzi, ovvero usa la memoria del processo per mantenere
> il valori tra le richieste.
>
> Ti consiglio per cose del genere di prendere in considerazione anche una
> variabile di sessione.
>
> -f