Forum: Rails Germany ein Formular mit Ajax Upload

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Franz M. (Guest)
on 2009-05-19 11:59
Hallo.

Ich habe einen Blog Eintrag mit den Felder Title, Inhalt, usw.
Zu jedem Blog Eintrag kann man mittles AJAX bis zu 5 Bilder hochladen
die direkt nach dem Hochladen in einer Galerie angezeigt werden.
Wenn der Benutzer dann auf Submit klickt, wird der Blog Eintrag
gespeichert.

Das Problem ist, dass der Blog Eintrag noch nicht existiert wenn die
Bilder hochgeladen werden.
Leider hab ich noch keine Optimale Lösung für das Problem gefunden.

Variante 1)
Im Controller den Blog Eintrag mit BlogEntry.create(..) erzeugen. Dann
kann ich die Bilder beim Upload mit dem BlogEntry verknüpfen. Der
Nachteil ist bei dieser Variante, dass viele leere Datenbankeinträge
erzeugt werden, wenn der User nach dem new() Aufruf abbricht.

Variante 2)
Blog Eintrag mit BlogEntry.new(ohne id) erzeugen.
In new wird ein zufälliger Schlüssel erzeugt. Beim Upload wird zu jedem
Bild dieser Schlüssel gespeichert.
Wenn dann der Blog Eintrag abgeschickt wird werden alle Bilder mit dem
zufälligen Schlüssel dem Eintrag zugeordnet.
Nachteil: Diese Variante ist etwas kompliziert zu handhaben, vor allem
wenn dann später beim bearbeiten des Eintrags wieder Bilder gelöscht
bzw. neue hinzugefügt werden.

Gibt es eine bessere Möglichkeit für das Problem, sodass z.b. bei
Variante 1 keine unnötigen Einträge erzeugt werden. Wäre es sinnvoll das
Ganze in einer Transaktion ausführen?

lg
Michi
Michael S. (Guest)
on 2009-05-19 12:22
(Received via mailing list)
On Tuesday 19 May 2009, Michael .. wrote:

> Ich habe einen Blog Eintrag mit den Felder Title, Inhalt, usw.
> Zu jedem Blog Eintrag kann man mittles AJAX bis zu 5 Bilder hochladen
> die direkt nach dem Hochladen in einer Galerie angezeigt werden.
> Wenn der Benutzer dann auf Submit klickt, wird der Blog Eintrag
> gespeichert.
>
> Das Problem ist, dass der Blog Eintrag noch nicht existiert wenn die
> Bilder hochgeladen werden.
> Leider hab ich noch keine Optimale Lösung für das Problem gefunden.
[schnipp; zwei Varianten]

> Gibt es eine bessere Möglichkeit für das Problem, sodass z.b. bei
> Variante 1 keine unnötigen Einträge erzeugt werden. Wäre es sinnvoll
> das Ganze in einer Transaktion ausführen?

Das ist immer sinnvoll, hilft hier aber nur bedingt, weil du
transaktionale Ressourcen, nämlich die Datenbank, mit nicht-
transaktionalen, dem Dateisystem, mischt.

Habe ich dich richtig verstanden, dass es grundsätzlich möglich ist,
dass der Benutzer Bilder hochlädt, aber nie einen Blogeintrag dazu? Dann
schlage ich vor Uploads (oder UploadBatches) und Blogeinträge logisch zu
trennen. Der Ablauf sieht dann so aus:

- Der Benutzer öffnet das Blogformular.
- Er lädt mehrere Bilder auf den Server.
- Die Anwendung assoziiert mit jedem Bild ein Upload-Objekt in der
Datenbank.
- Der Benutzer schreibt einen Blogeintrag und speichert ihn.
- Die Anwendung verknüpft den Blogeintrag mit den schon erzeugten
Upload-Objekten.
- Periodisch löscht die Anwendung Upload-Objekte, die seit einer
bestimmten Zeit herrenlos sind.

Das ist natürlich deutlich komplizierter als deine Vorschläge.
Allerdings wirst du voraussichtlich um regelmäßige Hintergrundjobs
ohnehin nicht herumkommen, da kannst du auch gleich damit anfangen.

Michael

--
Michael S.
mailto:removed_email_address@domain.invalid
http://www.schuerig.de/michael/
Thomas r. K. (Guest)
on 2009-05-19 12:23
(Received via mailing list)
Variante 3)
Bilder haben keine post_id sondern sind habtm.
Weniger Stress, mehr Möglichkeiten.
Beim Bild-Upload kriegst die ID zurück und kannst
die ja gleich ins new_post form packen.

ciao, tom

--
Thomas R. "TomK32" Koll || http://tomk32.de || http://ananasblau.com
just a geek trying to change the world
Skype: TomK32 || Mail: removed_email_address@domain.invalid
http://flickr.com/people/tomk32
This topic is locked and can not be replied to.