क्लास-आधारित विचारों का क्या लाभ है?

Question 1

मैंने आज पढ़ा कि Django 1.3 अल्फा शिपिंग है, और सबसे अधिक टाल दिया गया नया फीचर क्लास-आधारित विचारों का परिचय है ।
मैंने संबंधित दस्तावेज़ीकरण पढ़ा है , लेकिन मुझे उनका उपयोग करके प्राप्त होने वाले बड़े लाभ ™ को देखना मुश्किल लगता है , इसलिए मैं उन्हें समझने में कुछ मदद के लिए यहां पूछ रहा हूं।
आइए प्रलेखन से एक उन्नत उदाहरण लेते हैं ।

urls.py

from books.views import PublisherBookListView

urlpatterns = patterns('',
    (r'^books/(\w+)/$', PublisherBookListView.as_view()),
)

views.py

from django.shortcuts import get_object_or_404
from django.views.generic import ListView
from books.models import Book, Publisher

class PublisherBookListView(ListView):

    context_object_name = "book_list"
    template_name = "books/books_by_publisher.html",

    def get_queryset(self):
        self.publisher = get_object_or_404(Publisher, name__iexact=self.args[0])
        return Book.objects.filter(publisher=self.publisher)

    def get_context_data(self, **kwargs):
        # Call the base implementation first to get a context
        context = super(PublisherBookListView, self).get_context_data(**kwargs)
        # Add in the publisher
        context['publisher'] = self.publisher
        return context

और अब इसकी तुलना एक "सादे-पुराने-विचार" समाधान से करते हैं, इस प्रश्न के लिए 5 मिनट में खुद से बनाया गया है (मैं इसमें किसी भी त्रुटि के लिए माफी चाहता हूं)।

urls.py

urlpatterns = patterns('books.views',
    url(r'^books/(\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

views.py

from django.shortcuts import get_object_or_404
from books.models import Book, Publisher

def publisher_books_list(request, publisher_name):
    publisher = get_object_or_404(Publisher, name__iexact=publisher_name)
    book_list = Book.objects.filter(publisher=publisher)

    return render_to_response('books/books_by_publisher.html', {
        "book_list": book_list,
        "publisher": publisher,
    }, context_instance=RequestContext(request))

मेरे लिए दूसरा संस्करण दिखता है:

कार्यक्षमता में बराबर
बहुत अधिक पठनीय ( self.args[0]? भयानक!)
छोटा
डीआरवाई-अनुपालन कम नहीं

क्या कोई बड़ी चीज मुझे याद आ रही है? मुझे उनका उपयोग क्यों करना चाहिए? क्या वे दस्तावेज हैं? यदि ऐसा है तो आदर्श उपयोग का मामला क्या होगा? क्या मिक्सकिन उपयोगी हैं?

जो भी योगदान देता है, उसके लिए अग्रिम धन्यवाद!

उन लोगों के लिए पीएस जो आश्चर्यचकित कर सकते हैं, मैं कभी भी सामान्य विचारों से रोमांचित नहीं था: जैसे ही मुझे कुछ उन्नत कार्यक्षमता की आवश्यकता थी, वे नियमित विचारों से कम नहीं हो गए।

Question 2

आप विशिष्ट मामलों के लिए get_context_data जैसे एक वर्ग को परिष्कृत और परिष्कृत कर सकते हैं, और शेष को इस तरह छोड़ सकते हैं। आप कार्यों के साथ ऐसा नहीं कर सकते।

उदाहरण के लिए, आपको एक नया दृश्य बनाने की आवश्यकता हो सकती है, जो सब कुछ पिछले एक करता है, लेकिन आपको संदर्भ में अतिरिक्त चर शामिल करने की आवश्यकता है। मूल दृश्य को उप-वर्ग करें और get_context_data विधि को ओवरराइड करें।

साथ ही, टेम्पलेट को अलग-अलग तरीकों से रेंडर करने के लिए आवश्यक चरणों को अलग करना स्पष्ट कोड को बढ़ावा देता है - एक विधि में जितना कम किया जाता है, उतना आसान यह समझना है। नियमित दृश्य फ़ंक्शंस के साथ, यह सभी एक प्रोसेसिंग यूनिट में डंप हो गया है।

Question 3

अगर self.args[0]आपको परेशान कर रहा है, तो विकल्प है:

urlpatterns = patterns('books.views',
    url(r'^books/(?P<slug>\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

तब आप self.kwargs['slug']इसके बजाय उपयोग कर सकते हैं , जिससे यह थोड़ा अधिक पठनीय हो जाएगा।

Question 4

आपका उदाहरण फ़ंक्शन और वर्ग सुविधाओं में समान नहीं हैं।

वर्ग आधारित संस्करण मुफ्त के लिए पेजेशन प्रदान करता है और GET की तुलना में अन्य HTTP क्रियाओं का उपयोग करने से मना करता है।

यदि आप इसे अपने फ़ंक्शन में जोड़ना चाहते हैं, तो यह बहुत लंबा होने जा रहा है।

लेकिन यह वास्तव में अधिक जटिल है।

Question 5

यह पहली बार मैं यह सुन रहा हूँ - और मुझे यह पसंद है।

जो लाभ मैं यहाँ देख रहा हूँ, ईमानदारी से, वह यह है कि यह समग्र रूप से Django के साथ अधिक सुसंगत बनाता है। मॉडल कक्षाएं हैं और मैंने हमेशा महसूस किया है कि विचार भी होना चाहिए। मुझे पता है कि सब कुछ नहीं है, लेकिन विचार और मॉडल दो भारी इस्तेमाल किए जाने वाले प्रकार हैं ।

तकनीकी लाभ के लिए के रूप में? खैर, पायथन में सब कुछ एक वर्ग ( या वस्तु ?) है - तो क्या वास्तव में कोई अंतर है? क्या यह 99% सिन्थेटिक चीनी नहीं है?

Question 6

क्लास आधारित विचारों के बारे में सोचने का एक तरीका यह है कि वे प्रशिक्षण पहियों के साथ एक Django व्यवस्थापक की तरह हैं और इसलिए बहुत अधिक लचीला (लेकिन समझने में अधिक कठिन)।

उदाहरण के लिए व्यवस्थापक में सूची-प्रदर्शन स्पष्ट रूप से सामान्य सूची दृश्य पर आधारित है। सबसे सरल सूची दृश्य आप केवल एक मॉडल या क्वेरीसेट को परिभाषित करेंगे।

class MyExampleView(ListView);
    model = ExampleModel

आपको अपने स्वयं के टेम्पलेट की आपूर्ति करने की आवश्यकता होगी, लेकिन यह मूल रूप से सबसे बुनियादी मॉडल एडमिन के समान होगा। मॉडल व्यवस्थापक में list_display विशेषता यह बताएगी कि किस फ़ील्ड को प्रदर्शित करना है, जबकि सूची दृश्य में आप टेम्पलेट में ऐसा करेंगे।

class SpeciesAdmin(admin.ModelAdmin):
    list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)

व्यवस्थापक के साथ आपके पास एक पैरामीटर है

list_per_page = 100

जो प्रति पृष्ठ कितनी वस्तुओं को परिभाषित करता है। सूची दृश्य है

paginate_by = 100

जो वही हासिल करता है। इसी तरह यदि आप व्यवस्थापक को भारी रूप से अनुकूलित करते हैं, तो आप बहुत अधिक ओवरलैप देखेंगे।

यहां इस साइट को आपको बेहतर विचार देना चाहिए कि वे क्या करते हैं।

http://ccbv.co.uk/