Mongoose: القدرة على تحديد ES6 الذي يعد باستخدامات النمس في المكتبات

أتطلع حقًا إلى أن تكون قادرًا على استخدام Promise.all () ، للقيام بشيء ما بعد الانتهاء من جميع أعمال قاعدة البيانات.

: +1:

الشيء الوحيد الذي لم يكن واضحًا جدًا على https://github.com/LearnBoost/mongoose/issues/1699 هو ما سيكون التنفيذ الافتراضي.

حسنًا ، نظرًا لأنه ليس إصدارًا مقلقًا ، يجب أن يكون mpromise هو الخيار الافتراضي ، لكنك ستكون قادرًا على التجاوز.

+1

: +1:

هل يوجد فرع يتم فيه اختراق هذا؟ لا أستطيع تحمل تدفق معالجة الخطأ مع mpromise وأنا على وشك فتح المصدر لمعرفة ما سيستغرقه ذلك.

الوعد:

  query.exec()
    .then(function(ou) {
      if(!ou) {
        return next(new errors.http.NotFound('The specified OU was either not found, or your credentials lack the required permissions to view it.'));
      }

      res.send(ou);
    }, next)
    .end(next);

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

طائر أزرق:

  query.exec()
    .then(function(ou) {
      if(!ou) {
        return next(new errors.http.NotFound('The specified OU was either not found, or your credentials lack the required permissions to view it.'));
      }

      res.send(ou);
    })
    .catch(next);

يبدو أن القيام بـ promisifyAll(require('mongoose')) لا يزال يعمل مع Mongoose 4 حتى الآن. هل ستكون اختبارات الانحدار التي تغطي هذا مستهدفة للغاية؟

ليس الان. سيتم تنفيذ معظم العمل في وحدة kareem وفقًا لـ # 2754 و vkarpov15 / kareem # 2 ، لأن ذلك سيسمح لنا بقتل عصفورين بحجر واحد وإزالة اللقطات الفوضوية حقًا التي تمت كتابتها لعمل خطافات ووعود نعمل معا. لا تتردد في التعامل مع ذلك ، فأنا منفتح على العلاقات العامة.

لكن لماذا يجب أن نحافظ على دعمنا لمكتبة الوعود الأخرى؟ أصبحت مواصفات ES6 Promises الآن صلبة للغاية وهي باقية. ألا يمكننا فقط استخدام وعود ES6 الخالصة ، مع تحميل polyfill عندما لا تكون متوفرة في الإصدارات القديمة من العقدة؟

إذا كان الأمر كذلك ، فيمكنني تجربتها.

النقطة المهمة هي أنك ستتمكن من استخدام أي مكتبة وعود متوافقة مع ES6 تريدها. لا يزال الكثير من الأشخاص يستثمرون بكثافة في بلوبيرد ، عندما ، q ، rsvp ، وما إلى ذلك ، وكل من هذه المكتبات لديها المراوغات الخاصة التي لن يلتقطها polyfill العام.

أنا منفتح على الاقتراحات البديلة - لا أحب الوعود ولا أستخدمها على وجه التحديد ، فهذه الميزة مدفوعة بحقيقة وجود عدد كبير من المشكلات التي تتضمن أشخاصًا يطلبون "دعم ميزة Bluebird X في mpromise" أو "دعم rsvp.js الأصلي "والسماح للناس بإحضار مكتبة وعودهم إلى الحفلة هو أسهل طريقة لإغلاق هذه القضايا.

أرى ما تعنيه. أنا مستخدم كبير ومؤيد للوعود. أعتقد أنه ينبغي النظر في تطبيق المعيار.
تم اختيار وعود A + لتكون بمثابة الانتقال إلى ES6. لقد اقترحت polyfill لضمان دعم إصدارات العقدة غير المتوافقة ES6 (على سبيل المثال ، https://github.com/jakearchibald/es6-promise).

يجب أن تكون في أيدي مكتبة الوعود الأخرى لتكون متوافقة وقابلة للاختلاط مع وعود ES6.

تعديل:
ولن يكون هناك اختراق لواجهة برمجة التطبيقات الحالية أم أني أفقد شيئًا ما؟

تختلف مواصفات Promises / A + كثيرًا عن مواصفات وعود ES6 ، والتي بدورها تختلف عن مكتبات الوعود التي أدرجتها في التعليقات السابقة. في حين أنه سيكون من الجيد بالنسبة لي أن يتم دمج جميع المكتبات التي لا تعد ولا تحصى في ES6 ، إلا أنني أشك في أن هذا سيحدث على الإطلاق ، لأن جمال المصدر المفتوح هو أن بعض الأشخاص الذين يحبون الوعود سيريدون ميزات إضافية وسيكتبون وعودهم الخاصة المكتبات.

لا يوجد تغيير جذري لواجهة برمجة التطبيقات الحالية ، ما أفكر فيه هو طريقة لقول mongoose.set('Promise', require('bluebird')); أو شيء من هذا القبيل ، لذلك سيكون خيار الاشتراك ويكون تقديم الوعود هو الخيار الافتراضي.

أوه صحيح ، آسف لهذا الخطأ.
لقد ألقيت نظرة على التطبيق الحالي ومكتبة الوعود الأخرى.

أعتقد أنه يمكنني عمل شيء مثل هذا:

mongoose.set('Promise', Promise);

mongoose.set('Promise', require('bluebird'));

mongoose.set('Promise', require('q').defer());

mongoose.set('Promise', require('when').defer());

// and so on...

لذلك ، يجب أن تعرض للنمس وعدك بكائن الاختيار الذي يحتوي على طرق resolve و reject .

هل هذا ما كان يدور في ذهنك؟ إذا كان الأمر كذلك ، فسأعمل على طلب سحب.

تعديل:
إنه أمر سخيف للغاية أن تكتب mongoose.set('Promise', Promise); . أعتقد أن ES6 يجب أن يكون الافتراضي ، مع إمكانية استخدام المكتبة التي تختارها (والوعود عندما لا تتوفر وعود ES6).

بالتأكيد ، سأكون ممتنًا لمساعدتك. سيكون الجزء الصعب هو 1) جعله يعمل مع الخطافات - راجع vkarpov15 / kareem # 2 ، و 2) مما يجعله متوافقًا مع mpromise.

أيضًا ، بخصوص: Q ، سنستخدم require('q').Promise نظرًا لأن هذا هو بناء جملة Q الأقرب إلى مواصفات ES6

شكرا لمساهمتك ، ستعمل على ذلك. هل تفضل طلب سحب منافس أم علاقات عامة مستمرة؟

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

+1 لهذه الميزة. أود استخدامها مع بلوبيرد

نأسف لكونك متطرفًا - لكن النهج البديل قد يتمثل في إهمال الوعود بالدعم تمامًا. هذا من شأنه أن يصمت أي شخص يستخدم الوعود التي تطلب دعم المكتبات الأخرى.
يمكن للأشخاص الذين يستخدمون مكتبات الوعود القوية مثل بلوبيرد الاستمرار في استخدامها على أي حال نظرًا لأنك تعرض واجهة برمجة تطبيقات لرد الاتصال ويمكن لـ بلوبيرد أن يلف ذلك بشكل تافه بتكلفة 0 - في الواقع هناك احتمالات أنه نظرًا لأنك لا تعرف أو تستخدم الوعود (كما قلت) سيكون أبطأ وأكثر عرضة للخطأ لدعمهم يدويًا على أي حال.

benjamingr 100٪ يختلفون. الآن مع دمج iojs و NodeJs في Node 3.0 ، سيكون هناك دعم لـ ES6 Promises and Generators.

سيكون إسقاط الدعم خطوة كبيرة إلى الوراء.

أي أن Promise.promisifyAll(require("mongoose")) يُنشئ غلافًا سريعًا (أسرع من أي محاولات يدوية محتملة) لـ Mongoose وهو شكوى معيارية ويحيط بكل واجهة برمجة التطبيقات دون الحاجة إلى فعل أي شيء حيال ذلك. في الواقع ، يمكنك عمل Promise.promisifyAll على كائن الصادرات بنفسك وفضح وعود بلوبيرد وطريقة الوعود المزدوجة (save - saveAsync) مجانًا ، ثم قل أنك تعرض واجهة الوعد بلوبيرد دون الحاجة إلى القيام بأي عمل فعلي.

لذلك ، بينما أستخدم بلوبيرد وعود نفسي - أعتقد أن هذا الأمر برمته يمكن إصلاحه من خلال قسم في المستندات بدلاً من تعقيد الكود الخاص بك عن طريق الترميز إلى واجهتين.

albertorestifo إلا أنه لن يتم إسقاط أي شيء فعليًا. أنا مدرك تمامًا لما هي الوعود (أكثر من 1500 نقطة و 500 إجابة في تجاوز سعة المكدس: P) وأنا مسؤول أيضًا عن بعض أجزاء كيفية عملها في io.js (مثل https://github.com/ nodejs / io.js / قضايا / 256).

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

benjamingr الذي يفترض أن المرء يستخدم مكتبة Promise خارجية. أنا ملتزم بالواحد الموجود في المواصفات ، وأنت تعلم جيدًا ، ليس به غلاف.

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

benjamingr الذي يفترض أن المرء يستخدم مكتبة Promise خارجية. أنا ملتزم بالواحد الموجود في المواصفات ، وأنت تعلم جيدًا ، ليس به غلاف.

إذا اخترت استخدام تطبيق بطيء ويصعب تصحيحه وأقل ثراءً بالميزات ، فهذا بالطبع هو اختيارك: P ولكن كيف يرتبط ذلك بالغلاف؟ من السهل تمامًا كتابة غلاف مشابه لـ Bluebird's promisifyAll باستخدام الوعود الأصلية *.

إذا كنت ترغب في الحصول على نسخة ممكّنة من Mongoose بوعد كحزمة منفصلة ، فإليك كيفية القيام بذلك:

• الخطوة 1 ، افتح المحرر المفضل لديك أو مجرد محرر توافق عليه نوعًا ما.
• الخطوة 2 ، اكتب module.exports = require("bluebird").promisifyAll(require("mongoose"))
• الخطوة 3 ، قم بإنشاء ملف package.json مناسب ، انشر على npm
• الخطوة 4 ، عشرات الآلاف من التنزيلات.

الآن ، أعرف ما تفكر فيه "هذا لا يستخدم الوعود الأصلية" ، حسنًا ، لا يزال بإمكانك حذف كل طريقة باستثناء then و catch من النموذج الأولي للوعد و all و race من Promise وينتهي الأمر بنفس واجهة برمجة التطبيقات - أو يمكنك فقط إخبار الأشخاص بأنك تصدر وعودًا محلية - لن يعرفوا نظرًا لأنهما مجرد وعودان / A + عمليات التنفيذ ، أعدك ؛)

(* كتابته بسرعة أصعب على مستوى المستخدم لأنه لا توجد طريقة سريعة لإنشاء وعود في الوقت الحالي وهذا هو السبب في أن io.js من المحتمل أن يصدر وظيفة وعد بحد ذاتها في النهاية - وهذا يعني من خلال أخذ مُنشئ الوعد فأنت تجبره على ذلك كن بطيئًا على أي حال).

هذا بالتأكيد بديل لائق. أود أن أحافظ على وعود داخلي ، لأنه ، سواء أعجبك ذلك أم لا ، فهذه هي الطريقة التي سيستخدم بها المستخدمون النمس ، لذلك قد يكون لدينا أيضًا تغطية اختبار قوية له ، حتى نتمكن من الإشارة والقول "هذه هي الطريقة يمكنك استخدام مكتبة الوعد X مع النمس ". الجانب السلبي عند فصل الأشياء إلى وحدات منفصلة هو أنه من الصعب أن تقول "حسنًا ، هذا الإصدار من وعود النمس يعمل فقط مع النمس 3.8 ، وهذا يعمل مع النمس> = 4.1" ومن الصعب على النمس تجنب كسر غلاف الوعود الشامل .

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

لماذا تريد / تحتاج إلى تغطية اختبارية لذلك؟ لا جدوى من اختبار الوعود في شفرتك - فالمكتبات لديها اختبارات بالفعل - وهذا يشبه اختبار الوحدة النمطية http عند استخدامها.

ومن الصعب على النمس تجنب كسر غلاف الوعود الشامل.

يقوم Bluebird بشيء بسيط حقًا - فهو يعثر على نماذج أولية ثم يضيف طرقًا لها لاحقة Async - هذا أمر بسيط حقًا ويعمل جيدًا في الممارسة - إنه عبارة عن بطانة واحدة بها معظم المكتبات بما في ذلك Mongoose ولم تنكسر ولو مرة واحدة في العام الماضي.

لست متأكدًا من سبب رغبتك في الحفاظ على الكثير من تعليمات التركيب التي من المحتمل أن تكون عرضة للخطأ ، فالاضطرار يدويًا إلى دعم اثنين من واجهات برمجة التطبيقات مع حالات الحافة الخاصة بهما تبدو وكأنها الكثير من العمل ويمكنك كسر الأشياء كما تذهب - يمكنك "استعارة" برنامج Bluebird's promisifyAll وقم بتكييفه للعمل مع مكتبات الوعد الأخرى (فهو مفتوح المصدر بعد كل شيء) لكنني بالتأكيد لن أفعل ذلك يدويًا.

"حسنًا ، لا يعمل هذا الإصدار من وعود النمس إلا مع النمس 3.8 ، وهذا يعمل مع النمس> = 4.1" ومن الصعب على النمس تجنب كسر غلاف الوعود الشامل.

حسنًا ، هل تمانع في إعطائي مثالًا على تغيير جذري يجب أن يحدث إذا كان التعهد تلقائيًا؟

1) أود اختبار الأشياء بالطريقة التي يستخدمها المستخدمون بها.

2) أرغب في أن أكون كسولًا وأن أتجنب ذلك ، لكن كما أفهم ذلك ، فإن معظم المكتبات الأخرى لا تملك تعهدًا. أفترض أن هذا هو السبب في أن "دعم ميزة Xpromise Y" هي أكثر طلبات ميزة النمس شيوعًا. علاوة على ذلك ، ليس لدينا أي نية لإعادة كتابة تعهد بلوبيرد ، فقط اجعل وظائف النمس تعيد الوعد أصلاً.

3) يعتمد على تنفيذ الوعد وكيف تستخدمه :)

1) أود اختبار الأشياء بالطريقة التي يستخدمها المستخدمون بها.

ماذا تقصد باختبار الطريقة التي يستخدمها المستخدمون؟ هل يمكنك أن تريني تشبيهًا لردود الاتصال؟

2) أرغب في أن أكون كسولًا وأن أتجنب ذلك ، لكن كما أفهم ذلك ، فإن معظم المكتبات الأخرى لا تملك تعهدًا. أفترض أن هذا هو السبب في أن "دعم ميزة Xpromise Y" هي أكثر طلبات ميزة النمس شيوعًا. علاوة على ذلك ، ليس لدينا أي نية لإعادة كتابة تعهد بلوبيرد ، فقط اجعل وظائف النمس تعيد الوعد أصلاً.

ليس عليك إعادة الكتابة ، يمكنك أن تأخذها - إنها ليست عامة لأن التنفيذ العام سيكون أبطأ.

كما أنه ليس من الكسل عدم التنفيذ اليدوي لميزة متاحة على نطاق واسع. هل NodeJS كسول لعدم وضعه في الصميم؟ هل TC39 كسول لعدم وضع شرطة سفلية في الصميم؟ من خلال التمسك باتفاقية (عمليات الاسترجاعات) ، فإنك تمنح المستخدمين القدرة على استخدام أيا كانت بدائية التزامن يريدون.

3) يعتمد على تنفيذ الوعد وكيف تستخدمه :)

حسنًا ، تعهد بلوبيرد ، أو Q's أو متى - تختلف في التنفيذ لكنهم جميعًا يفعلون نفس الشيء - لذا فقط اختر واحدًا يعجبك. أنا فقط أتساءل كيف ستنكسر.

هناك شيء واحد أفتقده في هذه المناقشة هنا:

إذا أعاد النمس وعدًا قياسيًا (وفقًا للمعيار الذي يعني التنفيذ الأصلي لـ ES6) ، ألا يجب أن يكون متوافقًا مع أي مكتبة Promise متوافقة مع ES6؟ يمكنني أن أفعل Promise.all([model.query().exec(), ...]) على ما يرام ، وكذلك Bluebird ، q ، عندما يكون مكافئًا.

فلماذا لا نعيد الاسترجاعات والوعود القياسية (مثلما تفعل الآن ، ولكن "التخلص" من mpromise) والسماح للمستخدم باستخدام مكتبة الوعد المفضلة لديه؟ أم أنني أفتقد شيئًا هنا؟

albertorestifo حسنًا ، الوعود المحلية بطيئة في الوقت الحالي وستستغرق بعض الوقت ، وربما سنوات قبل أن تصل إلى التكافؤ مع مكتبات userland - لذلك بشكل أساسي.

benjamingr قمت بعمل بعض النقاط الجيدة. تتمثل النقطة الأساسية لوعود النمس في تمكينك من استخدام yield مع عمليات mongoose غير المتزامنة دون أي مكتبة أخرى ، وهذا هو سبب وفائنا بوعودنا للمستقبل المنظور. IMO هذا شيء يجب أن يكون حقًا جزءًا من قلب النمس للمضي قدمًا.

هل س أو متى لها القدرة على التعهد؟

هل س أو متى لها القدرة على التعهد؟

نعم ، تقريبًا كل مكتبة وعود واسعة الانتشار أعرفها تقدم نوعًا من الوعود:

إليك الموعد: https://github.com/cujojs/when/blob/master/docs/api.md#nodeliftall
إليك سؤال: https://github.com/kriskowal/q/wiki/API-Reference#qnfbindnodefunc -args

الوعود الأصلية لم تحصل عليها حتى الآن ، ولكن هذا شيء يتم العمل عليه - بمجرد وجود مسار سريع لخلق الوعود (أي - ليس منشئ الوعد) ، فمن المحتمل أن تدعمه NodeJS في جوهر الوعود الأصلية (لأنه يمكن ذلك) أن يتم ذلك _ fast_ في أرض المستخدم).

النقطة الأساسية في وعود النمس هي تمكينك من استخدام العائد مع عمليات النمس غير المتزامنة دون أي مكتبة أخرى

أنت بحاجة إلى مكتبة من أجل استخدام yield بطريقة هادفة مع الوعود على أي حال. إذا كان بإمكانك كتابة 9 LoC التي تضخ المولد كوظيفة غير متزامنة بنفسك ، فيمكنك بالتأكيد كتابة وعد - وإذا كنت مثل معظم المستخدمين ، فإنك تستخدم مكتبة لذلك على أي حال.

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

الشيء هو أننا فعلنا ذلك بالفعل طريقة تلو الأخرى ، نحتاج فقط إلى تعديل غلاف الوعد الداخلي. في كلتا الحالتين ، لا يمكننا إزالة الوعود من الجوهر حتى 5.0. أنا منزعج لفكرة إهمالها ، تقدمbenjamingr بعض الحجج الجيدة التي سأفكر فيها عن كثب ، لكنني أعتقد أن الخطوة التالية ستكون # 2688 على أي حال.

من الواضح أنك تتمتع بخبرة أكبر مع Mongoose والأهم من ذلك أنها مع المستخدمين - لذلك أفهم هذا الاختيار. شكرا جزيلا لسماعك لي.

لقد قمت بكتابة "its" ولكن شعرت أن جهاز iPhone الخاص بي يجب أن يصححه تلقائيًا إلى "it's" وشعرت GitHub أن تحرير التعليقات ليس حالة استخدام مثيرة للاهتمام. آسف للتعليق المزدوج البريد العشوائي :)

يمكنك تعديل التعليقات على موقع الويب إذا قمت بالنقر فوق القلم الرصاص في الجزء العلوي الأيسر من تعليقك.

أنا منفتح دائمًا على نقاش جيد ، لا سيما النقاش الذي يعلمني شيئًا جديدًا: البيرة: قد أتصل بك لاحقًا لمناقشة المزيد :)

المستقبل ينتمي إلى الوعود المحلية ، على ما يبدو. يعتبر Mongoose معيارًا صناعيًا لعمليات mongo ، وهو صالح تمامًا للاعتماد على الوعود القياسية أيضًا.

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

iliakan ربما في المستقبل. لا أتوقع أن تصبح الوعود الأصلية هي "المعيار" حتى منتصف عام 2016 على أقرب تقدير ، فالمكتبات المتنوعة للوعود المجزأة مترسخة بعمق ولديها الكثير من المراوغات الدقيقة. في كلتا الحالتين ، لا يمكن أن ينتقل النمس إلى "أصلي بشكل افتراضي" بدون تغيير كبير في الاتجاه المعاكس.

@ vkarpov15 متأكد من أنني أفهم.

ما يمكن أن يكون مفيدًا في الوقت نفسه - صفحة بسيطة تحدد أوجه عدم التوافق الرئيسية بين الوعود المحلية. أشياء على الأقل لا يجب أن تجربها باستخدام mpromise ؛)

هل أفهم أنه لا يوجد catch الآن ، وتلك كل القيود؟

لا توجد فكرة ، لم تتعمق حقًا في ES6 API. يقوم .then() بتنفيذ Promises / A + ولا شيء آخر ، مما يعني عدم وجود .catch () ، وعدم وجود آثار مكدس طويلة ، وما إلى ذلك.

بشكل عام ، الشيء الذي ينفذ الوعود / A + ينفذ أيضًا وعود ES6 من منظور رفيع المستوى ، لكن العكس ليس صحيحًا. تعد Promises / A + محددة جدًا بشأن تفاصيل التنفيذ ذات المستوى المنخفض ، على سبيل المثال ، لا تلتزم بلوبيرد بالوعود / A + تمامًا ، ولست متأكدًا من مكتبات الوعود الشائعة الأخرى ، لكنني متأكد من أنها لا تلتزم بالمواصفات في طرقهم الفريدة. هذا ما سيجعل هذا صعبًا بشكل خاص.

تقصد ، يمكنك الآن استخدام بلوبيرد والوعود المحلية؟

نعم require('mongoose').Promise = global.Promise سيجعل النمس يستخدم الوعود المحلية. على الرغم من ذلك ، يجب أن تكون قادرًا على استخدام أي مُنشئ وعد ES6 ، ولكن في الوقت الحالي نختبر فقط باستخدام برنامج أصلي وبلوبيرد و Q

@ vkarpov15 هذا شيء عظيم! شكرا جزيلا!

@ vkarpov15 شكرا جزيلا! عمل عظيم!

نعم بالتأكيد. هذا رائع حقا! :)

@ vkarpov15 هذا حقا لطيف