Material-ui: [مستندات] جدول افتراضي

تم إنشاؤها على ١٧ يوليو ٢٠١٧  ·  55تعليقات  ·  مصدر: mui-org/material-ui

oliviertassinari هل تفكر في إضافة حاوية افتراضية إلى tbody لزيادة الأداء عند عرض قوائم طويلة بدون ترقيم الصفحات؟
سآخذ طعنة في هذا إذا كان بإمكانك توجيهي في الاتجاه الصحيح ( react-virtualized ؟)

Table docs good first issue

التعليق الأكثر فائدة

oliviertassinari لقد صنعته بدون react-virtualized لأنه كان في حالة من الفوضى ولم يلعب بشكل جيد مع مكونات mui.
علاوة على ذلك ، فإن الحل الحالي الخاص بي هو هيكل ثابت وقابل للتمرير مع ارتفاع جدول ديناميكي وعرض أعمدة ديناميكي (تم اختباره في Safari أيضًا).
يعد الجزء العلوي دائمًا مع tbody القابل للتمرير أمرًا ضروريًا لشبكات البيانات.

أقوم بإضافة تصحيح التمرير وتعديل الأداء وإصلاح بعض الخلل ولكنه يعمل بشكل رائع: أنا "فعليًا" أقوم بعرض حوالي 2400 صفًا ، على نحو سلس جدًا.

out

أسئلة حول مكونات Table :

  1. كيفية استخدام ref مع مكونات MUI؟ أنا أحسب ارتفاعًا تلقائيًا TableThead height: المشكلة هي ذلك
<TableHead ref={ ref => this.tableThead = ref }>

لا يُرجع عنصر حاوية DOM الفعلي لـ TableThead ولكن مثيل React (السلوك الأصلي لـ React عند تطبيق ref على عنصر ليس DOM) لأن هذا شيء يجب تطبيقه في TableThead المكون نفسه ؛ قد تحتاج المكونات الأخرى إلى هذا ، فلماذا لا يكون لديك refHandler على كل مكون MUI يطبق رد النداء المحدد في العنصر الأول المعروض؟ (آمل أن أكون قد تمكنت من شرح ذلك @ _ @)
الحل الحالي هو غريب

const theadHeight = ReactDOM.findDOMNode(this.tableThead).clientHeight; // eslint-disable-line react/no-find-dom-node

مما يعني استخدام findDomNode الموقوف وتعطيل eslint أيضًا.

  1. لماذا يتم تطبيق border-bottom على الخلايا بدلاً من الصفوف؟

  2. ماذا عن وجود خاصية stripe={true} لتخطيط صفوف TableBody تلقائيًا؟

  3. لماذا يحتوي .MuiIconButton.root على خاصية نمط zIndex؟ 🤔

آمل أن أنشر شيئًا مستقرًا حول هذا قريبًا حتى تتمكن من إلقاء نظرة على أنه شيء يمكن اعتماده بطريقة عامة.

آسف على الإزعاج كثيرًا ، لكني أستخدم mui @ بشكل كبير

ال 55 كومينتر

نأمل أن تسمح واجهة برمجة التطبيقات الحالية بالتكامل البسيط مع react-virtualized . نحن منفتحون على إجراء أي تغيير على التنفيذ من أجل جعل التكامل أبسط.

سيكون وجود مثال توضيحي في المستندات أمرًا رائعًا.

إذا كان ذلك يمكن أن يساعد ، فإليك مثال على التكامل مع القائمة / القائمة https://codesandbox.io/s/oQ0nkl5pk.

oliviertassinari لقد صنعته بدون react-virtualized لأنه كان في حالة من الفوضى ولم يلعب بشكل جيد مع مكونات mui.
علاوة على ذلك ، فإن الحل الحالي الخاص بي هو هيكل ثابت وقابل للتمرير مع ارتفاع جدول ديناميكي وعرض أعمدة ديناميكي (تم اختباره في Safari أيضًا).
يعد الجزء العلوي دائمًا مع tbody القابل للتمرير أمرًا ضروريًا لشبكات البيانات.

أقوم بإضافة تصحيح التمرير وتعديل الأداء وإصلاح بعض الخلل ولكنه يعمل بشكل رائع: أنا "فعليًا" أقوم بعرض حوالي 2400 صفًا ، على نحو سلس جدًا.

out

أسئلة حول مكونات Table :

  1. كيفية استخدام ref مع مكونات MUI؟ أنا أحسب ارتفاعًا تلقائيًا TableThead height: المشكلة هي ذلك
<TableHead ref={ ref => this.tableThead = ref }>

لا يُرجع عنصر حاوية DOM الفعلي لـ TableThead ولكن مثيل React (السلوك الأصلي لـ React عند تطبيق ref على عنصر ليس DOM) لأن هذا شيء يجب تطبيقه في TableThead المكون نفسه ؛ قد تحتاج المكونات الأخرى إلى هذا ، فلماذا لا يكون لديك refHandler على كل مكون MUI يطبق رد النداء المحدد في العنصر الأول المعروض؟ (آمل أن أكون قد تمكنت من شرح ذلك @ _ @)
الحل الحالي هو غريب

const theadHeight = ReactDOM.findDOMNode(this.tableThead).clientHeight; // eslint-disable-line react/no-find-dom-node

مما يعني استخدام findDomNode الموقوف وتعطيل eslint أيضًا.

  1. لماذا يتم تطبيق border-bottom على الخلايا بدلاً من الصفوف؟

  2. ماذا عن وجود خاصية stripe={true} لتخطيط صفوف TableBody تلقائيًا؟

  3. لماذا يحتوي .MuiIconButton.root على خاصية نمط zIndex؟ 🤔

آمل أن أنشر شيئًا مستقرًا حول هذا قريبًا حتى تتمكن من إلقاء نظرة على أنه شيء يمكن اعتماده بطريقة عامة.

آسف على الإزعاج كثيرًا ، لكني أستخدم mui @ بشكل كبير

لقد صنعته بدون تفاعل افتراضي لأنه كان في حالة من الفوضى ولم يلعب بشكل جيد مع مكونات mui.

أوه ، هذا عار علينا. أي فكرة عما يمكن أن نفعله لجعلها ممكنة؟

  1. يمكنك تجربة innerRef للحصول على مرجع على TableHead . سيحصل لك ref على مرجع لمكوِّن withStyles(TableHead) . إذا لم يفلح ذلك ، فيمكننا الكشف عن خاصية rootRef . هذا نمط نستخدمه بالفعل.

  2. لا دليل

  3. ماذا تقصد بشريط؟
  4. لقد قمت بإزالته في # 7467

~~أوه ، هذا عار علينا.

في الواقع هي مزيج من react-virtualized الحاويات الخاصة، مسقط رأسه table/thead/tbody عناصر DOM وضرورة وجود للتمرير tbody الذي تسبب في المشكلة.
كانت هناك حاجة إلى الكثير من العمل معها: كان مجرد عمل حل مخصص مقابل MuiTable أمرًا سهلاً.

  1. كشف rootRef سيكون رائعًا (بافتراض أن العنصر الرئيسي TableThead في طريقة render هو Thead DOM عنصر نفسه)

  2. هل يجب نقل border-bottom إلى tr إذن؟ هل يجب أن أنقل هذا إلى إصدار مخصص؟

  3. أعني الصفوف المخططة: من السهل تحقيقها باستخدام like tr:nth-child(odd) { backgroundColor: f2f2f2 ولكن نظرًا لأن لدينا بالفعل التلوين المفيد hover={true} فلماذا لا يكون لدينا striped={true} سهل الاستخدام؟ :)

  4. عظيم!

  1. 👍 يبدو وكأنه خطة ، وهنا مثال ، العلاقات العامة مرحب بها.
  2. يقوم Bootstrap بنفس الشيء ، وأعتقد أنه يوفر المزيد من المرونة من خلال استخدامه على TableCell .
  3. لأنها ليست في المواصفات ويمكن تنفيذها ببساطة على أرض المستخدم؟
  4. 👍
  1. لست متأكدًا من مجرد وجود ref={rootRef} على كل مكون.
    ربما يحتاج المطورون الذين يستخدمونه (في الغالب) إلى التحكم في DOM.
    في مثالك ، سيعيد <FormControl ref={rootRef} ...> مرة أخرى مرجعًا إلى مكون React (لأن FormControl ليس عنصرًا في DOM) وسيجعل المطور يستخدم الحل البديل الذي كان عليّ استخدامه.
    ربما يجب أن يتصرف rootRef كما يلي:

هل حاوية المكون الذي تم عرضه هي عنصر DOM؟

  • إذا كانت الإجابة بنعم ، فقم بتطبيق ref={rootRef} عليها
  • بخلاف ذلك ، قم بتطبيق rootRef={rootRef} عليه => والذي سينتشر وصولاً إلى عنصر DOM الأول: بهذه الطريقة سيكون للمبرمج دائمًا مرجع DOM الحقيقي

الحل الشامل الذي يمكنني التفكير فيه هو امتلاك خصائص muiRef و rootRef حيث يطبق الأول رد الاتصال على حاوية "mui component" (إن وجد) ويطبق الأخير رد الاتصال كما أنا قلت سابقا.
بهذه الطريقة يمكن للمطور أن يمتلك بسهولة كلا من MUI ref و DOM ref (كل ما يحتاج إليه ، وقتما يحتاج).
هل تعتقد أن هذا منطقي؟

  1. هل حقا؟ @ _ @

  2. العمليات! أنا دائما أنسى المواصفات المادية

  1. أوه ، لم أفكر في هذه القضية. القضية التي تشير إليها هي ما يلي:
  2. يأخذ المكون A خاصية ref rootRef وخاصية
  3. رد فعل اعتراض ref وطبقه على العنصر
  4. يتلقى المكون B خاصية rootRef ويطبقها كمرجع على جذر المكون C
  5. رد فعل اعترض هذا ref وقم بتطبيقه على العنصر

ولكن ماذا لو كان للمكون C أيضًا خاصية rootRef؟
يمكن أن يكون المكون A على أرض المستخدم ، ويمكن أن يكون المكون B هو TextField ويمكن أن يكون المكون C هو FormControl.

إذن إجابتي ، في البداية قدمنا rootRef كمساعد بسيط. لم نتحدث عن التصنيع. لذا ، أعتقد أن السلوك الحالي رائع بقدر ما حتمي وبسيط وبدون قيود تصفها ، إذا كان الأشخاص مهتمين بالوصول إلى عنصر dom الأساسي ، فيمكنهم استخدام

damianobarbati هل كان رد الفعل الافتراضي قائمة التجربة مع الجدول والمحاكاة الافتراضية المذكورة هنا ؟

أنا أخمن listComponent = TableBody ، itemComponent = TableRow؟

لقد بدأت هذا المشروع الذي يستخدم التفاعل الافتراضي مع Material 1.0 التي قد تكون مهتمًا بها.

https://github.com/techniq/mui-table

لا يزال العمل قيد التقدم (راجع https://github.com/techniq/mui-table/blob/master/TODO.md) ولكنه قد يكون مفيدًا لك. هناك نقص في المستندات ولكن ألقِ نظرة على القصص للتعرف على كيفية استخدامها.

techniq هذا يبدو واعدا 😄! أعتقد أنه سيكون من الرائع تجديد قسم وثائق الجدول في وقت ما للحصول على:
- https://github.com/DevExpress/devextreme-reactive~~ (رخصة تجارية)

يمكننا أيضًا إضافته إلى قسم https://material-ui-next.com/discover-more/related-projects/#material-ui-specific-projects.
لذا ، أخبرنا عندما يكون المشروع أكثر نضجًا. أعتقد أنه يمكننا قبول طلب سحب للترويج للمشروع :).

لقد قمت بعمل علاقات عامة مقابل react-virtual-list هنا https://github.com/clauderic/react-tiny-virtual-list/pull/30 مما يسمح باستخدامها مع واجهة المستخدم المادية. لقد جاهدت للحصول على رد فعل افتراضي للعمل وإنشاء HTML صالح لأنه يحتوي على تشفير ثابت div .

cc: kgregory

eyn عمل جميل! انتهيت للتو من تنفيذ جدول التمرير اللانهائي باستخدام التفاعل الافتراضي وواجهة المستخدم المادية. آمل أن أجمع الخلاصة معًا قريبًا. عندما أفعل سأقوم بربطها هنا لأي زائر مستقبلي لهذه المشكلة وربما كمثال في المستندات

kgregory هل انتهيت من

شكرا لعملكم!

neofox لا ، آسف. لم ألتف حول ذلك مطلقًا ، لكن ردك هو تذكير لطيف. سأحاول إيجاد الوقت لوضع شيء ما معًا.

oliviertassinari لا يعمل مثالك في إحدى التعليقات الأولى التي يُفترض أنها توضح كيفية استخدام قائمة المواد مع القائمة الافتراضية للتفاعل. هل ما زلت تملك هذا المثال؟

rolandjitsu آسف ، ليس لدي أي أمثلة. هذا ما يدور حوله هذا الموضوع :).

oliviertassinari حصلت عليه. اعتقدت أن هذه المشكلة تتعلق بالجدول وليس <List> ، أم أنها تغطي القوائم أيضًا؟

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

oliviertassinari أود أن material-ui @ التالية المدمجة مع التفاعل الافتراضي؟

@ hassan-zaheer نعم ، أعتقد أن العرض التوضيحي البسيط مع رد الفعل الافتراضي في نهاية صفحة مستندات الجداول سيفي بالغرض :).

مرحبا. حدث أن تعثرت في هذا الموضوع عند البحث عن مشروعي. أرغب في معرفة ما إذا كان هناك أي تحديث هنا بخصوص العرض التوضيحي أو وثائق الاستخدام؟ kgregory أو هل يمكنك تقديم أي نظرة ثاقبة في دمج الاثنين؟ سيكون من الجيد جعل الطاولة تبدو متماسكة مع الأناقة

@ zd-project يمكنك إلقاء نظرة على مشروعي mui-virtualized-table .

كان من المعتاد أن يكون mui-table من DOM مباشرة ويتيح لك استخدام أشياء مثل تخطيط position: sticky و <table> (امتدادات الصف / العمود ، والعرض التلقائي ، وما إلى ذلك) التي كانت صعبة مع التفاعل الافتراضي.

مع ذلك ، أضاف mui-virtualized-table تغيير حجم العمود من علاقات عامة لطيفة.

أين نحن من هؤلاء الشباب؟

techniq ، شكرًا على mui-virtualized-table ! انه لشيء رائع! هل هناك أي فرصة لدمجها في mui-org/material-ui ؟

سأكون سعيدًا إذا قام شخص ما بفتح العلاقات العامة التي تقدم عرضًا توضيحيًا للمستندات. بهذه الطريقة يمكننا فحص ما إذا كان بإمكاننا تحسين واجهة برمجة تطبيقات الجدول لتحسين التكامل مع استراتيجيات المحاكاة الافتراضية.

mastertinner لماذا نحتاج لإضافة هذا إلى الجوهر؟ المحاكاة الافتراضية هي استراتيجية تحسين. لا يقدم الجميع مجموعات بيانات كبيرة ، لذا لن أعبأ بها على عاتق الجميع.

mastertinner يمكننا البدء بالرجوع إلى المشروع في الوثائق ، على سبيل المثال هنا: https://material-ui.com/demos/tables/#advanced-use-cases :)

👍 يبدو وكأنه خطة

mastertinner بينما ما زلت أستخدمه (عند الحاجة إلى جدول mui الأحدث عندما لا أحتاج إلى محاكاة افتراضية ، ويمكنني الاستفادة من dom (باستخدام table ، tr ، td ، أو شبكة css للتخطيط ، وإزالة الحاجة إلى عرض أعمدة واضح ، وما إلى ذلك) وتمكين بعض الأنماط المتقدمة مثل رؤوس position: sticky المتعددة (مثل هذا )

قامتrogerstorm بتمويل هذه المشكلة بمبلغ 30 دولارًا. شاهده على IssueHunt

قررت التلاعب بهذا اليوم ، لا أوصي هذا ما أنتجته حتى الآن:
virtualize

يرجى المعذرة عن التأخير ، جهاز الكمبيوتر المحمول الخاص بي ليس رائعًا ، فهو يستخدم مكونات Material-UI ومكونات react-virtualized

joshwooding لقد فعلت نفس الشيء بالضبط الذي فعلته ، ظاهريًا + رأس ثابت (مع شريط التمرير على الجسم فقط) . إذا كان تطبيقك يستخدم ميزتين منفصلتين <Table> s ، فأعتقد أن لديك نفس المشاكل التي وجدتها.

  • لا تعمل دعائم محاذاة المواد (على سبيل المثال numeric ) ، لأنك قد تستخدم مكونًا مثل <div> للتخطيط داخل <TableCell> .
  • يمكنك منح خصائص css مقابل td و tr للعمل بشكل افتراضي بشكل صحيح. لا توجد طريقة لمنح height أو max-height إلى td و tr والمواد <TableCell> لها حشوة خاصة بها ، أشياء هامشية تجعلها تصنع من الصعب تحديد ارتفاع الصف.

حسنًا ، النقطة المكونة داخل <TableCell> أمر لا مفر منه. أتساءل ما إذا كنت قد حللت هذه المشكلة بطريقة أنيقة. إذا لم يكن الأمر كذلك ، أعتقد أنه من الصعب أن يكون رأسًا افتراضيًا + ثابتًا (مع شريط التمرير على الجسم فقط) مكونًا صغيرًا (صغيرًا مثل وظيفته) ومكونًا محددًا جيدًا.

worudso حاليًا ، لا يستخدم سوى <Table> واحد فقط

لقد قمت بإنشاء صندوق رمل يوضح استخدام واجهة المستخدم المادية والافتراضية التفاعلية لإنتاج جدول افتراضي. يستخدم هذا المثال الخاص رد الفعل الافتراضي لحجم الجدول إلى ارتفاع النافذة.

المكون MuiVirtualizedTable من المثال متاح أيضًا في هذا المضمون .

يمكن أن يقبل MuiVirtualizedTable أي خاصية يدعمها الجدول . لا يتم تطبيق rowClassName بشكل مباشر ، ولكن يتم تطبيقه بدلاً من ذلك بالإضافة إلى الأنماط الأخرى المحددة في MuiVirtualizedTable .

تتوقع الخاصية columns مصفوفة من الكائنات تُستخدم عند عرض خلايا لكل عمود. يمكن لكل كائن قبول أي خاصية يدعمها العمود .

اعتذاري لأخذ وقت طويل لقد كنت مشغولا.

لمعلوماتك ، يوجد الآن أيضًا react-window والذي من المفترض أن يكون الوريث react-virtualized . في حال أراد أي شخص أن يجرب ذلك.

kgregory شكرا لمشاركتك كوداندبوكس.

تضمين التغريدة إنه لأمر رائع أن يكون لديك رأس ثابت :). أتمنى أن تكون قادرًا على إكمال التنفيذ! فيما يتعلق بإعادة التوجيه الرقمية ، ما الذي يمنعك من التقديم مباشرة على الخلايا؟ رد فعل النافذة مقابل رد الفعل الافتراضي

oliviertassinari لقد حددت لنفسي هدف استخدام واجهة برمجة التطبيقات الخاصة بالمكون Table والآن لا يبدو أنه يمكنك تمرير الدعائم المخصصة عبر المكون Column . ربما توجد طرق للقيام بذلك دون استخدام طريقة التفاعل الافتراضية

oliviertassinari لقد حاولت استخدام HeaderRowRenderer ولكن يبدو أنه لا يمكنك تمرير الدعائم المخصصة من خلالها دون معالجة الدعائم الحالية لأن هذا هو ما يسمى لإنشاء الأعمدة لتمريرها إلى headerRenderer:

const renderedHeader = headerRenderer({ columnData, dataKey, disableSort, label, sortBy, sortDirection, });

oliviertassinari للحصول على جدول ارتفاع ثابت ، يمكنك فقط تعديل العرض التوضيحي لـ kgregory قليلاً: https://codesandbox.io/s/6vo8y0929k

@ joshwooding تبدو رائعة! لا يمكنني التفكير في أي شيء مفقود لجعله عرضًا توضيحيًا رسميًا.

قامت issuehuntfest بتمويل 60.00 دولار لهذه المشكلة. شاهده على IssueHunt

oliviertassinari سأعمل على تنفيذ هذا :)

قدّم joshwooding طلب سحب. شاهده على IssueHunt

oliviertassinari كافأ 81.00 دولارًا إلىjoshwooding. شاهده على IssueHunt

  • : حقيبة النقود: إجمالي الإيداع: 90.00 دولارًا
  • : tada: مكافأة المستودع (0٪): 0.00 دولار
  • : مفتاح الربط: رسوم الخدمة (10٪): 9.00 دولارات

oliviertassinari كافأ 81.00 دولارًا إلىjoshwooding. شاهده على IssueHunt

عن جدارة. عمل جيد @ joshwooding!

لدي حاجة مماثلة ولكن لمكون القائمة ... هل سيعمل نفس النهج على عمل القائمة؟

mdizzy نعم ، يمكننا إضافة عرض توضيحي مماثل للقائمة.

أحاول الآن إنشاء قائمة افتراضية باستخدام نافذة رد الفعل (كما اقترح المنشئ لاستخدامها بدلاً من المحاكاة الافتراضية إذا لم تكن بحاجة إلى واجهة برمجة التطبيقات الكاملة ، ولكن في النهاية ، لا تتغير واجهة برمجة التطبيقات لقائمة بالفعل بهذا القدر)

حتى الآن لدي مشكلتان كبيرتان:
1) نمط عناصر القائمة معطل ، خاصة بالنسبة لأشياء مثل الرموز / الإجراءات الصحيحة. أعتقد أن أسلوب القائمة الافتراضية المحقونة لا يلعب بشكل جيد مع التصميم من واجهة المستخدم المادية
2) تصبح العناوين الفرعية اللاصقة فوضوية حقًا أيضًا ، ربما لنفس السبب (استخدم موضع نافذة التفاعل المطلق لتخطيط العناصر)

سأحاول على الأرجح التفاعل الافتراضي لمعرفة ما إذا كانوا يعملون بشكل أفضل معًا

MastroLindus أفترض أنك جربت عرض المحاكاة الافتراضية أولاً؟

oliviertassinari لقد بدأت بطريقتي الخاصة ، ووجدت المشكلات التي وصفتها أعلاه ،

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

إن قضاياي تتعلق بالقوائم أكثر قليلاً. يعمل المفهوم العام ، لكن أشياء مثل الرموز والإجراءات والعناوين اللاصقة لا تعمل بشكل صحيح.
بالتفصيل ، بالإشارة إلى نقطتي في التعليق أعلاه:
قد تكون المشكلة رقم 1 مشكلة في نافذة رد الفعل التي لن تكون موجودة في رد الفعل الافتراضي. سأخبرك بمجرد أن أحاول ذلك اليوم أو غدًا. ربما نكون محظوظين وسيعمل فقط مع التفاعل الافتراضي. دعونا نرى.
المشكلة رقم 2 (العناوين الفرعية اللاصقة لا تعمل بشكل صحيح) أعتقد أنه شيء سيحتاج إلى حل خاص على أي حال ، حيث من المحتمل أن يؤدي تحديد مواقعهم إلى حدوث تعارض مهما كان الأمر. قام شخص ما ببناء https://github.com/marchaos/react-virtualized-sticky-tree لمشكلة مماثلة (وجود صفقة افتراضية تفاعلية مع رؤوس ثابتة) ولكن لم يكن لدي الوقت للنظر فيها الآن

MastroLindus ما هي المشكلات التي نواجهها مع https://next.material-ui.com/demos/tables/#virtualized -table؟

oliviertassinari لا شيء.
لقد حددت أن مشاكلي خاصة بالقوائم الافتراضية ، وليست الجداول الافتراضية. (مرة أخرى: أنا آسف لأنني أكتب عن مشكلة Table Virtualized ، لا يوجد شيء للقوائم الافتراضية وكنت أتابع تعليق mdizzy )

فيما يتعلق بالقوائم: لا يبدو أن استخدام ListItemSecondaryAction و ListItemIcon و ListSubheader (مع الرؤوس الثابتة) يعمل ، حيث يتم إفساد تحديد المواقع.
بدون هذه المكونات ، حصلت على قائمة أساسية للعمل مع نافذة رد الفعل (وأعتقد أنني سأفعل الشيء نفسه في رد الفعل الافتراضي)

MastroLindus أعتقد أنه يمكنك نقل المناقشة إلى # 15149.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات