ja hallo erstmal,…
Am Samstag, 13. Oktober 2007 schrieb Tom Winkler:
Moinsens,
wo fange ich denn mal an 
Rails ist sehr eigen, was den richtigen Weg angeht. Prinzipiel geht
aber trotzdem alles, was man moechte, der große Unterschied
zwischen dem selbstgewaehlten und dem Rails-Weg ist allerdings, das
man sehr sehr viel mehr Arbeit investieren muss, wenn
man seinen Kopf durchsetzen moechte. Wenn irgendwas zu schwer ist,
dann ist man meistens auf dem falschen Weg.
Sicher, das ist bei jedem Framework / jeder Sprache so.
Speicherplatz und dein /tmp wird mit der Zeit richtig schoen gross.
Gibt’s denn kein Timeout?
Meines Wissens nicht, wo soll das Timeout herkommen? Du kannst dir
einen Cronjob basteln, der die Files immer mal wieder loescht.
Cron? Wenn jmd. mit der Anwendung arbeitet, sollte es genug nutzbare
trigger
geben.
Du solltst ja eben keine Objekte irgenwohin serialisieren. Sondern
eben nur die IDs und dann diese wieder damit aus der Datenbank holen.
Die Sessions als schnellen Zugriffsspeicher zu nutzen, ist nicht der
Sinn des ganzen. Wenn dir die Datenbank zu langsam ist - dann kannst
du eine geeignete Loesung wie memcached oder dergleichen einsetzen.
Ok, um die Ausführung mal auf den Punkt zu bringen: Es geht mir nich darum,
Objekte außerhalb der Datenbank zu persisitieren, sondern Objekte, erst
nach
dem “Create”-Formular in der Datenbank persistiert werden sollen
create-Formular gedrückt wurde) für Ajax-Calls zur Verfügung zu stellen.
Konkret: Wir verwalten Firmen und Adressen. Beide stehen in einer
n:m Beziehung. Vom Workflow der Anwendung her gibt es eine Maske, mitder
Firmen bearbeitet werden können. (Create & Edit sieht gleich aus - gleiches
Form-Partial).
In diesem Formular können einer Firma per Ajax Adressen zugewiesen werden:
D.h. Es muss möglich sein, einer Firma Adressen zuzuweisen, bevor die Firma
in
der Datenbank existiert.
Im create-Fall wäre ein Weg:
Ich lege das Objekt in spe schon in der DB ab und speichere die ID. Das
würde bedeuten, dass die Firmen persistiert werden muss, bevor die erste
Adresse
angelegt werden kann. D.h. ich persistiere Firmen, bevor der User auf
create
gedrückt hat. Bei diesem Weg (ist das der rails Weg?) müsste die DB-Struktur
erheblich angepasst werden. (-> Sehr viel Aufwand bei größeren Anwendungen)
Der andere Weg ist:
Ich lege das Objekt in der Session ab - bis zu dem Zeitpunkt, wo es das
erste
Mal wirklich in der DB persistiert werden kann - ab dann arbeite ich mit
IDs.
#73 Complex Forms Part 1 - RailsCasts
#74 Complex Forms Part 2 - RailsCasts
Ist interessant und zeigt für 1:n Beziehungen sicherlich einen schönen Weg -
bedeutet aber, dass ich alle Adressen in Formular-Feldern persistieren
muss.
D.h. alle Adressen werden bei einem create oder update mit Formulardaten
überschrieben. Könnte es aber nicht passieren (da n:m), dass vers. Benutzer
sich gegenseitig Daten überschreiben? Ebenweil sehr viele Adressen, die auch
von anderen Firmenobjekten referenziert werden, neu geschrieben werden?
(Derzeit ist es bei uns so, dass immer nur per Ajax einzelne, bestimmte
Adressen bearbeitet werden)
(Mir pers. gefällt an der Lösung auch nicht, dass bei einer Firma mit vielen
Adressen immer alle Addressen in einer HTML-Seite abglegt werden. Das
bläht
ein wenig…)
Wie ist eigentlich der Rails-Weg, um im “Create”-Modus mit n:m
Referenzen
umgehen zu können?
Wenn du einen Presenter brauchst, dann schau dir mal
http://agilewebdevelopment.com/plugins/simplypresentable oder aehnliche
Loesungen an.
Ist nicht so ganz das was ich suche…
Trotzdem danke.
Alles Gute
