Moin Michael,

danke für die ausführliche Beschreibung deines Problems. Es entsteht
natürlich dadurch, dass beim MVC-Pattern die Models und die Controller
sauber getrennt sein sollten. Ein Model, das hinterrücks auf einen
Controller zugreift, um sich den entsprechenden Parameter-Value
rauszusuchen, ist also eigentlich schon eine MVC-Violation.

Aber du hast ja schon eine gute Lösung gefunden: Eine Hilfsmethode im
Controller, die für das Holen der paginierten Model-Instanzen
verantwortlich ist. Eine solche Methode kann natürlich auf alle Parameter
des Controllers zugreifen und die sauber definierte Schnittstelle des
Models verwenden. Ich kann daran jedenfalls nichts Schlechtes finden. Alle
anderen Lösungen, die mir so spontan einfallen, haben größere Nachteile.

----- WERBEBLOCK -----
Kommt alle zu meinem kostenlosen Ruby Pair Programming, da können wir vor
Ort über genau solche Themen sprechen! Das wird super! Yeah! Wenn das
Problem interessant ist, dann von mir aus auch Remote:
http://gidsy.com/activities/5674/ruby-pair-programming
----- WERBEBLOCK ENDE -----


Viele Grüße
Ralph von der Heyden



2012/1/18 Michael Schuerig <michael.li...@schuerig.de>

>
> Ich verwende in einer Anwendung für die Paginierung Kaminari, das auf
> ARec-Model-Klassen die Scopes #page und #per definiert. Das ist schon
> mal ein guter Anfang, aber lästig ist es schon, wenn ich in Controllern
> ständig schreiben muss
>
>  Foo.page(params[:page]).per(20)
>
> Es ist immerhin möglich, für Model-Klassen mit paginates_per einen
> Defaultwert für die Anzahl der Listenelemente pro Seite festzulegen.
> Aber diese Definition steht an der falschen Stelle, jedenfalls für
> meinen Zweck: Die Anzahl pro Seite hängt bei mir gerade nicht vom Model
> ab, sondern vom Controller.
>
> Auf Controller-Ebenen würde ich daher gerne schreiben
>
>  paginates :foo, :per => 20
>  paginates :bar, :per => 10
>
> und dann in den Action-Methoden
>
>  Foo.paginated
>
> wobei paginated die Werte für "per Seite" und params[:page] aus dem
> Kontext des Aufrufers holen soll. Anders gesagt, ich hätte gerne
> Variablen mit dynamischem Scope, nicht dem in Ruby üblichen statischen
> Scope.
>
> Simulieren kann man das ansatzweise so
>
> class ActiveRecord::Base
>  def self.paginated(&block)
>    params = eval("params", block.binding)
>    page(params[:page]
>  end
> end
>
> Diese Methode muss dann aber als
>
>  Foo.paginated {}
>
> aufgerufen werden, damit es einen Block gibt, dessen Binding man sich
> hinterrücks greifen kann. Abgesehen davon ist eval furchtbar unschön.
>
> Um diese ganzen Schwierigkeiten zu umgehen, kann man die Paginierung
> natürlich auch im Controller definieren und dann schreiben
>
>  paginated(Foo)
>
> So mache ich das auch, aber die andere Schreibweise gefällt mir viel
> besser. Hat jemand einen Vorschlag, wie man sie ermöglichen könnte?
>
> Michael
>
> --
> Michael Schuerig
> mailto:mich...@schuerig.de
> http://www.schuerig.de/michael/
> _______________________________________________
> rubyonrails-ug mailing list
> rubyonrails-ug@headflash.com
> http://mailman.headflash.com/listinfo/rubyonrails-ug
>
_______________________________________________
rubyonrails-ug mailing list
rubyonrails-ug@headflash.com
http://mailman.headflash.com/listinfo/rubyonrails-ug

Antwort per Email an