2012-01-29 14 views
15

Girdi doğrulama, Django projelerinde model düzeyinde doğrulamadan ayrı mıdır? Örneğin, bir kullanıcı adının adlandırma ölçütlerine uyduğunu doğrulamak giriş doğrulaması ve kullanıcının veritabanında bulunmadığını doğrulamak, model düzeyinde doğrulama olur.Django'da form formu ve model doğrulama ayrılıyor mu?

Bir iş arkadaşının koduna bakıyorum ve her iki tür geçerliliğini bir form sınıfında (forms.py'de) yerleştirdiler. Bu tipik kurulum mu, yoksa model düzeyinde doğrulama model veya görünümde görünmesi daha yaygın mı?

Veya buna yaklaşmanın daha iyi bir yolu var mı? ModelForm kullanıyor gibi? Django’ya oldukça yeni ve bu durum için önerilen modelin ne olduğunu öğrenmeye çalışıyorum.

cevap

12

Bu çok ilginç bir soru (benim için).

Kanımca, tüm doğrulama kodları model koduna taşınmalıdır. İş kurallarını çiğnemenin yolu budur. Doğrulama kodu modelde olduğunda, yeni bir formda bazı doğrulamaların unutulması veya çeşitli biçimlerde tutarsız kuralların bulunması mümkün değildir.

Sizinle ilgili olan 'Django, Raise a validation error in a model's save method' sorusunu size bağlarım. Aşağıda, kodunu görerek, formlardan modeline kod doğrulamalarının nasıl geçtiğini görebilirsiniz. Umarım bu kısa tanıtım size yardımcı olabilir.

Hangi çerçeveden geliyorsunuz? Çevrenizde doğrulama kuralları nasıl yazılır?

+3

Katılıyorum. Çoğu şey gerçekten "model seviyesi" doğrulama olarak düşünülebilir. Adlandırma ölçütleriyle eşleşmiyorsa, veritabanına vurmak için bir kullanıcı adı istemezsiniz. Formdan forma değişecek bazı şeyler vardır ve bu, formun kendisinde doğrulamak istediğiniz yerdir. Bir alanda dosya türünü tutan bir fantezi Dosya modeliniz olabilir. Herhangi bir tür, model düzeyinde tamam, ancak fotoğraf yükleme formunda, örneğin png ve jpeg ile sınırlamak istersiniz. – dokkaebi

8

Kabul edilen cevaba katılıyorum. Modellerdeki tutarsızlıkları ve siteye özgü kısıtlamalar için form düzeyinde doğrulamadan kaçınmak için model düzeyinde doğrulama kullanmayı tercih ediyorum.

Başlama ve bitiş zamanı için datetime alanlarıyla, etkinlikler için bir modelimiz olduğunu varsayalım. Model doğrulama, başlangıç ​​zamanından sonra gelen bir bitiş süresine sahip olmamızı zorlayacaktır. Ancak, yeni oluşturulan olayın geçmişte olmadığını doğrulamak için formda bırakırım. Bu nedenle, geçmişte meydana gelen bir olay eklemek zorunda kalırsam, geçmişte tarihlere izin veren bir yönetici formu kullanabilir veya doğrudan veritabanına ekleyebilirim. Bu nedenle, model validasyonu sadece patenti yanlış olan değerleri kontrol etmelidir. ancak bir şeyleri funky (örneğin bir bot için bir kullanıcı adında Unicode karakterleri) yapmanız gerekiyorsa, bunu sadece yönetici veya kabuktan olsa bile yapmanıza izin vermelisiniz. Sürekli doğrulamadan faydalanmak için her zaman arka plan kodunda formları kullanan ve alanları form["field"] = "value" gibi kodlarla dolduran StackOverflow hakkında bir cevap okudum.

+1

Örnek senaryonuz için, 'event' tablosunda userId alanına sahip olabilir ve bazı grup kullanıcıları için geçmiş tarihlerle doldurma formuna izin verebilirsiniz. Gönderdiğiniz her örnek için bunun gibi bir karşı örnek bulabilirim;) Fakat bu benim yaklaşımımdır, bazı kurallardan emin olduğumdan emin olmak için doğrulama en iyi çözüm olacaktır. – danihp

+0

Elbette, onu modelde de uygulayabilirsiniz, ancak daha sonra bunun yerine formda olması gereken bir işleve işlevselliği kazandırıyorsunuz. Blog modelinizi başka bir yerde yeniden kullanmak isterseniz, gönderinin "admin" adındaki bir kullanıcıda bir kullanıcıya ait olması neden önemlidir? Bu gereksinim bir siteden diğerine değişebileceğinden, modelin kendisinden çok, bir forma bırakılır.Gelecekte, – sleblanc

+0

belki de, web uygulamanızın tam dinlenme api olacaktır. Sadece bir örnek. Commet'inizi paylaştığınız için teşekkürler, hoş geldiniz. – danihp