2010-11-10 10 views
17

के पीछे एक मॉडल के बिना एक कस्टम व्यवस्थापक दृश्य बनाना संभव है मेरे पास एक ऑब्जेक्ट है जिसे मैं मॉडलों को प्राप्त करने वाले मॉडल के बजाय व्यवस्थापक के तहत उपयोग करना चाहता हूं। मॉडल। अगर मैं इसे मॉडल का वारिस करता हूं। मॉडल, यह ऑब्जेक्ट डेटाबेस में एक टेबल बनाएगा जो मैं नहीं चाहता। मैं केवल इस वस्तु को स्मृति में रहने के लिए चाहता हूं।क्या

एक समाधान मैं स्टैक ओवरफ़्लो पर अच्छे लोगों से मदद के साथ आया हूं, मैं व्यवस्थापक विचार बना रहा हूं, admin.py के तहत एक मॉडलAdmin (admin.site.register()) के माध्यम से इन कस्टम दृश्यों को पंजीकृत करें और इस मॉडल की तरह उपयोग करें गतिशील डेटा भंडारण (स्मृति में) के रूप में वस्तु।

चूंकि इस मॉडल की तरह मॉडल मॉडल से प्राप्त नहीं होता है। मॉडल, admin.site.register() (admin.py के तहत) इसे स्वीकार नहीं करता है और दिखाता है कि 'टाइप' ऑब्जेक्ट इज़ेबल नहीं है "त्रुटि जब मैं कोशिश करता हूं ब्राउज़र में यह उपयोग।

+0

आप एक विशेष मॉडल अप करने के लिए अतिरिक्त दृश्य हुक कर सकते हैं (और जो भी आप मॉडल है या नहीं करने के लिए संबंधित उन में करना चाहते हैं, करते हैं, यदि आप चाहें तो मैं इस समाधान के साथ एक जवाब पोस्ट कर सकते हैं), लेकिन मैं व्यवस्थापक स्रोत हैकिंग के बाहर, पूरी तरह से स्टैंडअलोन व्यवस्थापक दृश्य बनाने के किसी भी तरीके से नहीं जानते हैं। – eternicode

+0

@eternicode वास्तव में स्टैंडअलोन व्यवस्थापक दृश्य बनाने के लिए यह पूरी तरह से संभव है: मेरा उत्तर देखें। –

+0

@ डैनियल रोज़मन, आह, तो! मैंने पहले कभी उस कार्यक्षमता को कभी नहीं देखा है, हालांकि टीबीएच ने मुझे अभी तक इसकी आवश्यकता नहीं है। – eternicode

उत्तर

10

hmmm। हर किसी को आपकी सहायताके लिए शुक्रिया।

my_model_list.html 
    my_model_detail.html 

views.py के तहत::

class MyModel(object): 
    # ... Access other models 
    # ... process/normalise data 
    # ... store data 

@staff_member_required 
def my_model_list_view(request) #show list of all objects 
    #. . . create objects of MyModel . . . 
    #. . . call their processing methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_list.html', context, RequestContext(request)) 
    return HttpResponse(r) 

@staff_member_required 
def my_model_detail_view(request, row_id) # Shows one row (all values in the object) in detail  
    #. . . create object of MyModel . . . 
    #. . . call it's methods . . . 
    #. . . store in context variable . . . 
    r = render_to_response('admin/myapp/my_model_detail.html', context, RequestContext(request)) 
    return HttpResponse(r) 

मुख्य Django के तहत

मैं दो कस्टम टेम्पलेट है: समाधान मैं ऊपर आ गए हैं (:) बिल्कुल आपकी मदद के साथ इस प्रकार है यूआरएल।py:

urlpatterns = patterns( 
    '', 
    (r'^admin/myapp/mymodel/$', my_model_list_view), 
    (r'^admin/myapp/mymodel/(\d+)/$', my_model_detail_view), 
    (r'^admin/', include(admin.site.urls)) 
) 
+1

खुशी है कि आपने इसे स्वयं ही समझ लिया है। मैं बस टिप्पणी करने वाला था। एक मॉडल के बिना एक व्यवस्थापक दृश्य मूल रूप से एक सामान्य Django दृश्य है जो एक व्यवस्थापक टेम्पलेट का उपयोग एक नकली ModelAdmin उदाहरण के साथ करता है, जो मूल रूप से आप कर रहे हैं। मैंने कुछ कस्टम एडमिन-थीम वाले पेज बनाने के लिए इसे स्वयं किया है। – Cerin

2

सबसे सीधा जवाब "नहीं" है। Django बुक कहते हैं, व्यवस्थापक के लिए इस मामले में "संपादन विश्वसनीय उपयोगकर्ताओं संरचित सामग्री," संरचित सामग्री पदानुक्रम में व्यवस्थित और कॉन्फ़िगर मॉडल किया जा रहा है सेटिंग्स.py के माध्यम से। अधिक महत्वपूर्ण बात यह है कि यदि आपका ऑब्जेक्ट पूरी तरह से बतख नहीं करता है- मॉडल को टाइप करें। मॉडल अपेक्षाकृत रिश्तों के साथ पूरा हो जाएगा, व्यवस्थापक शायद पूरे स्थान पर अपवादों को टॉस करेगा।

हालांकि, जैसा मंत्र जाता है, "यह सिर्फ अजगर है।" आप व्यवस्थापक में किसी भी पेज को ओवरराइड कर सकते हैं। बस अपनी परियोजना में अपने स्वयं के टेम्पलेट्स बनाएं, और उन्हें पहले टेम्पलेट खोज में आएं। साथ ही, व्यवस्थापक/base.html को विरासत में रखते हुए, आप & प्रशासन प्रोजेक्ट के अनुभव को बनाए रखते हैं।

इस ऑब्जेक्ट के लिए अपने प्रशासनिक दृश्य और टेम्पलेट्स को किसी अन्य की तरह लिखें, लेकिन यह सुनिश्चित करने के लिए is_staff सजावट में विचारों को लपेटना सुनिश्चित करें कि विचार अनधिकृत उपयोगकर्ताओं द्वारा उपयोग से सुरक्षित हैं। टेम्पलेट्स/admin/object_list.html और object_form.html के साथ, शायद व्यवस्थापक/views.py में, एप्लिकेशन में रखें।

एक बार जब आप इन गैर-डेटाबेस ऑब्जेक्ट्स के लिए उचित व्यवस्थापकीय उपकरण प्राप्त कर लेते हैं, तो आप उन्हें व्यवस्थापकीय अनुक्रमणिका पृष्ठ के माध्यम से एक्सेस प्रदान कर सकते हैं: आप व्यवस्थापक/index.html को ओवरराइड करना चाहते हैं, और पृष्ठ पर अतिरिक्त प्रोजेक्ट-विशिष्ट आइटम प्रदान करना चाहते हैं जैसी जरूरत थी।

मैंने यह तृतीय पक्ष एपीआई को प्रशासनिक पहुंच प्रदान करने के लिए बिल्कुल किया है जो हमारे डेटा को स्टोर करते हैं, जैसे कॉन्स्टेंट संपर्क ईमेल सेवा, और यह बहुत अच्छी तरह से काम करता है।

+0

आपकी मदद के लिए धन्यवाद एल्फ। मैंने नीचे अपना समाधान जवाब पोस्ट किया है, हालांकि मुझे यकीन नहीं है कि मैंने आपकी सलाह का पालन किया है या नहीं। – sysasa

5

आप अपने विचार सीधे किसी भी ModelAdmin उपclass के बजाय AdminSite ऑब्जेक्ट पर जोड़ सकते हैं, जिसे आप पंजीकृत करते हैं।

डिफ़ॉल्ट AdminSite को django.contrib.admin.site के माध्यम से एक्सेस किया जाता है, जिसे आप रजिस्टर करते हैं और ऑटोडिस्कवर करते हैं। इसका उपयोग करने के बजाय, आप अपना स्वयं का सबक्लास और add your own views to it बना सकते हैं, और उसके बाद अपने मॉडल को डिफ़ॉल्ट के बजाय इसके खिलाफ पंजीकृत कर सकते हैं।

+0

दिलचस्प; मुझे लगता है कि इन सबक्लास को एक 'ऑटोडिस्कवर' कॉल द्वारा उठाया जाता है? या क्या आपके उप-वर्ग को पूरे साइट के ऐप्स में प्रभावी होने की आवश्यकता है? (असल में, मुझे लगता है कि मैं अवधारणा को सही तरीके से समझ नहीं रहा हूं ...) – eternicode

+0

आपकी मदद के लिए धन्यवाद डैनियल! समाधान नीचे पोस्ट किया गया है, हालांकि पूरी तरह से यह सुनिश्चित नहीं है कि आप यही चाहते हैं। वैसे भी, यह काम करता है! :) – sysasa