Django-tables2: خيارات التعريف ليست موروثة.

شكرا للتقرير هذا خطأ. إنه الآن على رأس قائمة المهام الخاصة بي.

شكرا.

لقد انتهيت تقريبًا من تنفيذ حل لهذا ، ثم تذكرت أنه بالنسبة Meta كنت أتبع أسلوب Django ، أي

class Meta(Parent.Meta):
    ...

لذا بدأت الآن أتساءل عما إذا كانت فكرة جيدة أن تحيد عن ذلك. أفترض أنه دائمًا ما كان غير متسق على أي حال ، في الفئة الفرعية الأولى من django_tables2.Table أنت _ لا تحتاج_ إلى القيام بـ class Meta(django_tables2.Tables): ، ولكن بالنسبة لأي فئات فرعية أخرى عليك فعلها.

أفترض أنه يمكنك القول على الرغم من عدم وجود واجهة برمجة تطبيقات django_tables2.Table.Meta ، وأنها فقط _starts_ في الفئة الفرعية الأولى. ما هو شعورك بهذا؟ هل تعلم كيف تعمل الوراثة الفوقية لنموذج Django وتتوقع أن تكون مختلفة هنا؟ أو كنت ساذجًا من واجهة برمجة تطبيقات Django ولذا فقد جربت للتو ما شعرت به _حسناء_؟

لقد أعدت للتو قراءة مشكلتك الأصلية ، ويبدو أن مشكلتك هي أنك لا تحاول حتى تغيير خيارات التعريف في الفئة الفرعية ، بل تحاول فقط إضافة فئة فرعية وإضافة أعمدة.

آسف ، لا أفهم بوضوح ما تقوله ، لكن نعم ، ما فعلته كان شعورًا صحيحًا. على أي حال ، أنا جديد تمامًا على مادة Meta ، لذا قد لا يكون أسلوبي جيدًا.

برادلي ،

أحب العمل في هذا المشروع. أواجه نفس المشكلة مثل applegrew هنا ، وتعليقك الأخير يطابق حالتي تمامًا.

### Table Definitions ###
# parent class 
import django_tables2 as tables

# generic parent class to handle table styling
class MyAppTable(tables.Table):
    class Meta:
        attrs = {'class': 'render-table'}


# subclass in a separate app
from myapp_helpers.tables import MyAppTable
from django_tables2.utils import A
import django_tables2 as tables

class ItemTable(MyAppTable):

    address_1 = tables.Column()
    address_2 = tables.Column()
    address_3 = tables.Column()
    city = tables.Column()
    state = tables.Column()
    zipcode = tables.Column()

    # need this to fix a bug with the meta class not passing through to subclasses in django-tables2
    class Meta(MyAppTable.Meta):
        pass


## Views ##

# class based view in separate app
from django_tables2 import SingleTableView

# Parent class to make pagination the same across views
class MyAppListView(SingleTableView):

    # default of 10 rows in every table on every page
    table_pagination = {"per_page": 10 }
    template_name = 'generic_list.html'


# subclass of view in local app
class ItemListView(MyAppListView):
    model = Item
    table_class = ItemTable

إذا لم يتم وضع تعريف الفئة Meta في ItemTable ، فلن يتم إرسال سمات التعريف التي تم تعيينها في الفئة الأصلية من خلالها. أرغب في إرسال نفس السمات إلى جميع الجداول في تطبيقاتي (التي ترث في النهاية من MyAppTable)

يعمل تحديد فئة Meta الفارغة في ItemTable التي ترث من فئة Meta الأصلية (MyAppTable) ، ولكن يبدو أنها تعمل ضد مبدأ DRY ، على الرغم من أنها عبارة عن سطرين فقط ولا تزال تفي بمتطلباتي بأن أحتاج فقط إلى تغيير فئة CSS في واحد بقعة يجب أن أحتاج إليها. نقدر العمل! شكرا لك.

أعلم من أين أتيت ، وأنا أميل إلى الاتفاق معك ، في الواقع لقد كتبت تصحيحًا جزئيًا لتنفيذ ذلك ، لكن هذا النهج يتعارض مع نهج Django مع العارضات. ومع ذلك ، فإن موقفي الحالي هو أن عمل الأشياء بطريقة مشابهة لـ Django أمر مهم للحصول على عمل المكتبة كما هو متوقع.

هل تعتقد أن الأمر يستحق حقًا الخروج من سلوك Django + Python القياسي لهذا؟

بعد أن طورت باستخدام Django / Python لمدة شهر تقريبًا ، لا أعتقد أنني مؤهل لتقديم حجة للانفصال عن القاعدة. أفترض أن هناك بعض الخيارات بالرغم من ذلك. يمكنك:

أ) قم بتوثيق الحل البديل كما هو مفصل أعلاه (إذا لم يكن كذلك بالفعل ، فقد أكون قد فاتني). إنه في الحقيقة ليس بهذا الرهيب.
ب) قم بتوفير سمة مثل "inherit_meta = False" التي يمكن تجاوزها في الفئات الفرعية للسماح للفئات الفرعية بوراثة المعلومات الوصفية. سيكون الإعداد الافتراضي خاطئًا للحفاظ على عمل الأشياء وفقًا لمعايير Django ، ولكنه سيسمح للأشخاص الأكثر ميلًا إلى المغامرة / الكسالى مثلي بإلغاء الحاجة إلى تكرار تعريفات فئة Meta. المشكلة الوحيدة التي أراها في ذلك هي الاحتفاظ بجزء إضافي من التعليمات البرمجية لحل بديل قد يؤدي إلى حدوث أخطاء (البيانات موجودة عندما لا تكون متوقعة) ، إلخ.
ج) اجعل هذا السلوك هو السلوك الافتراضي الجديد.

حتى وأنا أكتب هذا ، يمكنني بالفعل رؤية سيناريوهات في رأسي حيث يتم فحص متغيرات القالب بناءً على حقيقة أن الوراثة لا تحدث ، ويحدث الكسر ، وأقضي ساعات في البحث حول الكود فقط لأكتشف أنه تعطل لأنني تجاوز السلوك يدويًا. كما أنه لن يتطابق مع أي من الأمثلة الموجودة.

بصراحة ، ربما لا يستحق الأمر الجهد المبذول. أفضل أن أرى ملاحظة إضافية حول الميراث الفوقي "مسكتك" في الوثائق بدلاً من محاولة البرمجة في حل بديل لتوليد سلوك غير نمطي.

فيما يتعلق ب) ، يمكنك القيام بذلك على النحو التالي:

class Parent(tables.Table):
    class Meta:
        foo = 1

class Child(Parent):
    class Meta(Parent.Meta):
        bar = 2

Child.Meta لديه الآن foo = 1 _and_ bar = 2

أميل إلى الموافقة على أنه يمكن إصلاح ذلك بالوثائق.

شكرا. لقد قمت بالفعل بهذا في المثال الخاص بي بناءً على مثال applegrew.

دوه ، نقطة جيدة.

أحد الأمور المزعجة في الحل البديل هو أنه لا يمكنك تجاوز شيء ما في فصل الآباء:

class Parent(tables.Table):
    class Meta:
        attrs = {...}

class Child(Parent):
    class Meta(Parent.Meta):
         attrs = {'summary': 'A child table'}

يرفع NameError بـ name 'attrs' is not defined . ومع ذلك ، يبدو أن هذا يعمل ، لكنه قبيح:

class Child(Parent):
    class Meta(Parent.Meta):
        pass
     Meta.attrs['summary'] = 'A child table'

هل يوجد حل لهذا الخطأ حتى الآن؟ الحل أعلاه لا يعمل بالنسبة لي. http://stackoverflow.com/questions/21787938/inherit-and-modify-a-meta-class

لا أرى خوارزمية واضحة لدمج اثنين من العناصر التعسفية class Meta . فكر في حالات إضافة مفتاح إلى attrs ، وإزالة مفتاح من attrs ، واستبدال attrs بملاءة جديدة ، وما إلى ذلك. ربما أفتقد شيئًا ولكنه ليس كذلك من الواضح لي كيف ستفعل هذا بطريقة عاقلة.

يجب أن يكون السلوك هو نفسه كما لو كنت من الفئات الفرعية models.Model فئات.

لست متأكدًا من أنني أتابع ما تقوله. أنا أحاول فقط أن أرث meta من الفصل الأصلي وإضافة بضعة أعمدة. لقد قمت بتحديث الكود في سؤال SO أعلاه ، والذي نأمل أن يكون أكثر منطقية.

bradleyayers - إذا فهمت طلبك بشكل صحيح ، فيجب أن تكون قادرًا على متابعة منشور StackOverflow هذا للكتابة فوق Meta

pydolan نعم ، تحقق من http://stackoverflow.com/questions/21787938/inherit-and-modify-a-meta-class لبعض الأساليب الأخرى أيضًا.