Codeblogger wrote:
In der Regel muss man ja an anderer Stelle nochmal auf die Liste der
möglichen Werte zugreifen und dann macht es mitunter schon Sinn, die
Liste in einem Modell-Array abzulegen. Ich sehe aber ein, dass das
nicht unbedingt immer der Fall sein muss.
Genau, man muss oft nochmal auf die Liste aller möglichen Werte (zB
Select-Box), und das auch recht DRY bei beiden Plugins. Im Falle von
enum-column greift man auf alle Möglichkeiten laut documentation so zu:
> Model.columns_hash['color'].values
Im Falle enumeration-mixin werden alle Möglichkeiten ja in einer extra
Tabelle gespeichert, und ran kommt man mit:
> EnumModel.all
In beiden Fällen reicht validates_presence_of, was ja schon von Michael
erwähnt wurde.
Der Nachteil ist nun - und hier versteh ich auch einige die nach DRY
rufen - dass man die Auflistung zwar nicht doppelt macht, jedoch dass
die Auflistung der Möglichkeiten sich eben nicht im Quellmodel befindet.
Sondern einerseits in einer Migration zu finden ist
(enum-column-plugin). Oder aber in einer DB-Tabelle (und somit zB in
einer Fixture oder auch Migration), wie beim enumeration-mixin.
Andererseits ist das abspeichern von Strings als enum, wie zB bei
polymorphic associations angewendet, zwar innerhalb von ruby/rails DRY
und schick und seeeehr bequem. Jedoch wird sich jeder gut ausgebildete
Datenbank-Designer die Haare raufen beim Anblick einer String-Spalte die
als enum missbraucht wird. Ich weiß - Normalisierung interessiert nicht
allzu viele rails Leute, aber vieleicht sollte man mal öfter dran
denken. Und dank der Plugins kann auch der ruby code weiterhin gut
aussehen ;-)
Gruß
Thomas Neumann
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
