Die Absicht dahinter ist, dass in der Produktionsumgebung die statischen
Seiten direkt vom Webserver ausgeliefert werden. Aber es soll halt auch
während der Entwicklung mit Mongrel funktionieren.
auch wenn ich mir nicht ganz sicher bin, dass ich Deine Intention,
Michael S., richtig verstanden habe, und auch wenn der Screencast von
Ryan B. zu dem Thema sehr instruktiv ist, hätte ich einen Tipp, um
das Rad nicht neu zu erfinden:
Das habe ich in einem Projekt schon produktiv eingesetzt. Es ist nicht
hyper-komfortabel, aber erlaubt die Gestaltung vieler Routevariationen,
ermöglicht den Aufruf von direkt gerendertem Text, also z. B. in Deinem
Fall in
app/views/movies/index.html.erb:
<%= render :comatose=>‘indices/movies’ %>
Man kann auch lokale Variablen mitgeben, mit Liquid-Drops mehr Dynamik
(allerdings ggf. auch Sicherheitslecks) hineinbringen, das Page-Cacheing
in div. Granularität steuern, und ein Flansch zur Anbindung von
restful_authentication ist auch schon gelegt.
plötzlich verstehe ich das Problem nicht mehr. Ich habe gerade in einem
meiner Rails-Projekte unter app/views/posts/index.html.erb in etwas
Bedeutungsloses umbenannt, und in public/posts eine index.html angelegt.
Im RAILS_ENV development dann http://localhost:3000/posts/ aufgerufen,
und es geht: Die statische Seite wird geliefert. Wenn in der statischen
Seite nun JS enthalten wäre, das die anderen Actions triggert, sollte
das doch gehen, oder was blicke ich hier nicht?
Sorry, wenn das jetzt blöd gefragt ist, aber das interessiert mich jetzt
schon. rübekratz
Falls Du mal Zeit hast, kannst Du mir die Frage ja beantworten, so Du
magst.
Schon mal Danke und beste Grüße
[ofi]
auch wenn ich mir nicht ganz sicher bin, dass ich Deine Intention,
Michael S., richtig verstanden habe
Der Hintergrund ist, dass ich statische Seiten habe deren dynamischer
Inhalt vollständig per AJAX als JSON geladen wird. Für beides will ich
schöne URLs haben, die sinnvoll zusammen passen.
jetzt verstehe ich: Das Problem beschränkt sich auf die index-Action.
Puh, sorry, da fällt mir jetzt auch nichts ein, was nicht bloß ein
Workaround wäre. Sollte sich das ändern bzw. ich über eine Lösung
stolpern, werde ich an Dich denken. Im Gegenzug wäre es schön, wenn Du
vor mir eine Lösung findest (was vermutlich wahrscheinlicher ist), Du
hier über diese informieren könntest.
plötzlich verstehe ich das Problem nicht mehr. Ich habe gerade in
einem meiner Rails-Projekte unter app/views/posts/index.html.erb in
etwas Bedeutungsloses umbenannt, und in public/posts eine index.html
angelegt. Im RAILS_ENV development dann http://localhost:3000/posts/
aufgerufen, und es geht: Die statische Seite wird geliefert
zuzugreifen. Du wirst feststellen, dass es nicht geht. Die Erklärung
dafür, findet sich, glaube ich, in
rails/railties/lib/rails/rack/static.rb. Jedenfalls für Mongrel; ob das
bei Passenger auch wirksam ist, habe ich noch nicht herausgefunden.
Rails::Rack::Static unterscheidet jedenfalls nicht nach gewünschtem
MIME-Type, sondern liefert immer das, was dort mit Endung HTML
herumliegt.
jetzt verstehe ich: Das Problem beschränkt sich auf die index-Action.
Puh, sorry, da fällt mir jetzt auch nichts ein, was nicht bloß ein
Workaround wäre. Sollte sich das ändern bzw. ich über eine Lösung
stolpern, werde ich an Dich denken. Im Gegenzug wäre es schön, wenn
Du vor mir eine Lösung findest (was vermutlich wahrscheinlicher ist),
Du hier über diese informieren könntest.
Ich verstehe inzwischen immerhin, warum es nicht einfach geht, was ich
erreichen möchte. Sowohl Rails auf Mongrel etc. mit der
Static-Middleware (siehe irgendwo in Railties) als auch Passenger
berücksichtigen den Accept-Header, also die vom Browser gewünschten
MIME-Typen, nicht, wenn sie eine passende Datei herum liegen sehen. Ich
habe bei Passenger ein entsprechendes Ticket geöffnet[*]. Falls mir
jemand erklären kann, wie ich in einem Apache2-Modul, sofern mod_mime
geladen ist, den MIME-Typ einer Datei ermitteln kann, dann schreibe ich
auch selbst einen Patch.