Enterprise: دعم تكوين عنصر المستوى الأعلى

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

هل يمكن إضافة دعم لـ soho لإضافة دعم لتجاهل العناصر؟
في حالة الاستخدام الخاصة بنا

على سبيل المثال ، سيتم تجاهل العناصر ذات الفئة

.soho-ignore

ربما : ليس () المحدد سيكون مفيدًا؟

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

أعتقد أن الطريقة الأخرى للقيام بذلك هي عدم وضع قاعدة ids-enterprise على عنصر المستوى الأعلى هذا والذي سيكون بمثابة "لا".

<div class='ids-enterprise'>
   <!-- Soho / IDS stuff -->
</div>
<div class='anything-else-but-ids-enterprise'>
   <!-- Not Soho / IDS stuff -->
</div>

شكرا للنظر في الأمر tmcconechy ! هذا بالإضافة إلى مشكلتين أخريين (سأقوم بتسجيلهما) تمنع Infor Nexus من الترحيل إلى IDS (نحن على إصدار متشعب قديم من Soho) ، لذلك ستكون هذه مساعدة كبيرة.

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

tmcconechy ولكن ماذا عن سيناريو مثل هذا

    <div class="accordion ids-enterprise" data-demo-set-links="true" data-options="{'allowOnePane': false}">
      <div class="accordion-header">
        <a href="#"><span>Warehouse Location</span></a>
      </div>
      <div class="accordion-pane">
        <div class="accordion-content">
          <some-component-with-own-styles></some-component-with-own-styles>
        </div>
      </div>

بالنظر إلى الكود أعلاه ، كيف يمكننا التأكد من أن ids-enteprise css لن تعبث بـ "some-component-with-own-styles؟

من وجهة نظري ، فإن إضافة عنصر الجذر إلى cascade css من فكرة جيدة كبداية ، لكنني أعتقد أنه من أجل جعل enteprise css قابلة للاستخدام ، يجب أن تكون هناك طريقة لجعلها لا تتلاعب بأجزاء أخرى من التطبيقات ، إذا: ليس المحدِّد خيارًا ، فماذا عن البادئة لجميع فئات معرفات المؤسسة مع معرفات المؤسسة؟

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

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

أنا أشك فقط في أن هناك طريقة جيدة لإنشاء فئة not-ids تعمل على كل مكون بأكمله بغض النظر عن المكان الذي تضعه فيه. لذلك سيكون الأمر أكثر من حالة على حدة بالنسبة لذلك.

أتساءل عما إذا كانت إعادة الضبط الأكثر بساطة ستساعدك؟ الفوركس ... ids-reset

• هل سيعيد الخط والحشو والهامش وربما بضعة أشياء أخرى إلى جذر المستند؟

نوع من إعادة تعيين عكسي؟ قد تساعد في بعض الحالات ولكن بالتأكيد ليس كلها؟

قد أن تفعل خدعة

حسنا سوف نلقي نظرة مع هذا. هذا ليس بالسوء الذي كنت أتوقعه في البداية.

تعجبني فكرة البادئة بالمعرفات. في الواقع يطلق عليه مفهوم "العلامة التجارية". من المؤكد أنه تغيير جذري ولكن يجب أن يكون هو السبيل للذهاب إلى بنية css-Enterprisd في المستقبل.

أوافق على ضرورة ترجيح القيمة على التغيير المكسور.

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

لدينا حل في الإصدار 5.0 التالي حيث يكون كل مكون مكون ويب مع مغلف css وكل ملفات css ذات مساحة اسم. هذا من شأنه أن يرضي هذه القضية حتى إغلاق

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

يمكنك مراقبة هذا المشروع https://github.com/infor-design/enterprise-wc -> إنه بعيد المنال ولكن في وقت ما من العام المقبل يجب أن يتم إصدار شيء ما

تبدو واعدة حقًا!