Hallo,
ist es eigentlich möglich, eine Seite, deren URL Parameter enthält per page
caching zu cachen?
So was zum Beispiel:
http://domain_name.de/controller_name/action_name/12?x=120y=1200
Bei mir wir die Seite immer im Dateipfad
/controller_name/action_name/12
abgelegt. Die Parameter werden
wenn ich mich recht entsinne, dann sagen die docs, dass alle parameter
ignoriert werden...
damit hab ich mich auch schon mal rumgeärgert.
Am 12.02.2010 um 09:56 schrieb rubyonrails...@galt.de:
Hallo,
ist es eigentlich möglich, eine Seite, deren URL Parameter enthält per page
caching zu
hi,
naja das ist ja kein Rails Problem sondern die Einschränkung der Umgebung.
? ist und bleibt ein QueryString das an die Datei über geben wird. Und
die gecachte Datei ist nunmal
/controller_name/action_name/12
Pass doch deine Route an, so dass die Wert im Dateinamen sind, und gut:
Ja, das ist etwas uncool.
Am 12.02.2010 um 10:07 schrieb Peter Schröder:
wenn ich mich recht entsinne, dann sagen die docs, dass alle parameter
ignoriert werden...
damit hab ich mich auch schon mal rumgeärgert.
Am 12.02.2010 um 09:56 schrieb rubyonrails...@galt.de:
Hallo,
ist es
Ich dachte, da Rails die Parameter so schön als Hash aufdröselt, daß es
vielleicht auch für URLs mit Parametern eine Lösung anbietet.
Eine ähnliche Lösung habe ich bisher auch immer verwendet. Es erscheint mir
halt etwas Redungdant, wenn ich Werte übergeben möchte, und http bereits ein
Format
Hallo Michael,
ich habe das Gefühl, dass du Page Caching noch nicht vollständig verstanden
hast. Beim Page Caching wird eine statische HTML-Datei im Dateisystem angelegt,
die anschließend von Apache oder Nginx einfach so rausgerotzt wird. Und
statische HTML-Dateien können von Natur aus recht
Der PageCache speichert eine Seite. Wenn du eine Schnittstelle
anbietest wie du das vorhast und hierfür PageCache verwendest, dann
hast du einfach nicht verstanden wofür der PageCache da ist. Der
PageCache ist zum Cachen von Seiten! Und wie soll der Rails überhaupt
Einfluss darauf haben, da dieser
Haha, gleichzeitig! Danke Marco.
Am 12.02.2010 um 11:04 schrieb Marco Scholl:
Der PageCache speichert eine Seite. Wenn du eine Schnittstelle
anbietest wie du das vorhast und hierfür PageCache verwendest, dann
hast du einfach nicht verstanden wofür der PageCache da ist. Der
PageCache ist zum
Webentwickler sind eigentlich gewohnt..
Rails-Entwickler sind da eben etwas anderes gewohnt! ;-)
Beste Grüsse,
Roman
Am 12.02.2010 um 10:53 schrieb rubyonrails...@galt.de:
Webentwickler sind eigentlich gewohnt,
___
rubyonrails-ug
Hallo,
ich habe just in diesem Moment Ärger mit diesem Thema. Daher hier mal kurz
meine vermeintlichen Erkenntnisse:
Wie schon mehrfach gesagt ist Page Caching dazu gedacht, statische HTML-Dateien
anzulegen, die dann direkt vom vorgeschalteten Webserver ausgeliefert werden
ohne das Rails davon
Hi,
genau deswegen habe ich bereits geschrieben das der FragmentCache
interessant ist.
Der ActionCache speichert die Action und geht davon aus das sich die
Action nicht ändert,
so wie der PageCache davon ausgeht, das die Seite sich nicht ändert.
Cachen ist ein sehr schwieriges Problem. Es gibt
Ach nochwas, bevor man ein Reverse Proxy vor den RailsServer schlatet,
sollte sich mal die Rack::Middleware anschauen,
damit kann man sehr schöne Caching sachen selber bauen, die dann z.B.
die Parameter beachten kann. Die läuft auch vor dem Rails.
Damit könnte man schön das Problem vom 1 Post
Der PageCache speichert eine Seite.
Ich hatte ja nicht behauptet, daß PageCaching etwas anderes macht, als Seiten
cachen.
Aber eben nicht nur HTML-Seiten. Ich verwende es für allen möglichen Output,
der sich selten ändert: xml-Dateien, generiertes Javascript etc. Kannst auch
CSV-Dateien oder
Wenn du weist, das Rails nicht involviert ist, wie soll Rails den das
Ganze beeinflussen. Klar könnte Rails die Datei mit den Parametern im
Dateinamen ablegen, aber welcher Parameter kommt zu erst (reihen
folge), was ist mit GET POST PUT DELETE? Damit sowas geht, müsste man
dem Webserver selber
Rail soll die Seiten nur ablegen
Einen GET-request(was anderes brauche ich nicht) für
http://www.domain.de/test.html?x=1y=2
Etwas so (kodiert) (im /public/cache)
test.html%3Fx%3D1%26y%3D2
Und dann müßte noch der Apache Rewrite so angepaßt werden, daß er die Anfrage
On Friday 12 February 2010, rubyonrails...@galt.de wrote:
Sobald eine Datei also gecached ist, wird Rails gar nicht mehr
involviert! Deshalb ist das auch so schnell. Seite Page-Gecached =
Hat nix mehr mit Rails zu tun. Rails kann demnach auch keine
Parameter aufdröseln
Daß Rails nach
Dann schick im Anschluss wenn's geht mal die ModRewrite Rule,
würde gerne sehen wie du es schaffst die Parameter zuvor zu sortieren.
Damit er auch immer schön die Datei findet. Wenn man das wirklich
neutral gebaut bekommt was ich nicht glaube, könnte man daraus ja ein
Plugin machen.
Alles andere
Ja das geht auch.
Im Moment teste ich das, indem ich den content aus dem Response-Objekt mit dem
entsprechenden Dateinamen ins cache-Verzeichnis schreibe.
Hast aber recht, page_cache_file wäre der geeignetere Ort dafür.
Am 12.02.2010 um 12:10 schrieb Michael Schuerig:
On Friday 12 February
Wieso willst Du denn unbedingt die Parameter sortieren?
Am 12.02.2010 um 12:19 schrieb Marco Scholl:
Dann schick im Anschluss wenn's geht mal die ModRewrite Rule,
würde gerne sehen wie du es schaffst die Parameter zuvor zu sortieren.
Damit er auch immer schön die Datei findet. Wenn man das
Naja wenn es eine Schnittstelle ist, könnte jemand x und y auch
andersrum senden und dann findet er die Datei nicht.
Am 12. Februar 2010 12:25 schrieb rubyonrails...@galt.de
rubyonrails...@galt.de:
Wieso willst Du denn unbedingt die Parameter sortieren?
Am 12.02.2010 um 12:19 schrieb Marco
Doch klar. Wenn die Datei nicht gefunden wird, dann geht's halt ab zu Rails und
dann wird eben die gleiche Datei unter einem zweiten Namen nochmal gecacht, der
die Parameter in umgekehrter Reihenfolge enthält. So what? Das wird die
Festplatte nicht killen:
- test.html%3Fx%3D1%26y%3D2
-
Das war doch das was ich gesagt habe :D Weil von alleine wird der das
Pattern nicht kennen.
Am 12. Februar 2010 14:17 schrieb rubyonrails...@galt.de
rubyonrails...@galt.de:
Bei der Anwendung, um die es geht, da sind es, wie ich ja bereits geschrieben
habe, max. 7 Parameter, die übergeben
Ich habe bei einem ähnlichen Problem mal den NGinx den Cache-Key,
unter dem er sucht in den Header des Requests schreiben lassen. Dann
konnte Rails den entsprechenden Inhalt unter dem Key ablegen. So habe
ich die Cache-Key-Generation nur noch an einer Stelle. Wir benutzen
das seit eine
23 matches
Mail list logo
