عرض تخطيطات مع العمود الفقري

Question

إذا كنت ترغب في إنشاء تطبيق ويب على صفحة واحدة (SPWA) باستخدام Backbone.js و JQuery-على سبيل المثال-تطلب كل منهما وحدات تحكم كل منها تتطلب تخطيطات صفحات فريدة ، كيف ستقدم التخطيط؟

• Controlera هو تصميم الأعمدة ثلاثة.
• ControlRB هو تخطيط عمود.
• يقوم المسار الافتراضي بتنشيط Controlla.welcome () - العرض الأولي.
• يتمتع كل من وحدات التحكم بوجهات نظر مختلفة يتم تقديمها ضمن أعمدةها والتي تستفيد من جميع طراز/طريقة عرض Backbone.js.

المشكلة

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

فكرتي الأولى

هل يمكنك استخدام طريقة عرض Backbone.js لتقديم التصميم ، ثم تقديم كل عمود مع طرق عرضه المرتبطة بالنموذج؟

فكرتي الثانية

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

إليكم مقتطفًا لفكرتي الثانية:

var Controller = Backbone.Controller.extend
({
    routes :
    {
       "" : "welcome" // default action
    }
    /** Constructor **/
    ,initialize: function(options)
    {
        console.log('Workspace initialized');               
    }
    // LAYOUT
    ,renderLayout : function ()
    {
        console.log('Rendering Layout.');
        var $ = window.$;
        var layout = require('js/layout/app/big_menu');
        $(layout.parent).html(layout.html);
    }
    // ACTIONS
    /** Default Action **/
    ,welcome : function ()
    {
        this.renderLayout();
        console.log('Do the whole model/view thing...');
    }
});

شكرا لك

شكرا لأخذ الوقت للرد. أنا أقدر ذلك!

Answer 1

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

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

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

Answer 2

أميل إلى الاتفاق مع جوليان - من الجيد أن تبقي تخطيطاتك عديمة الجنسية قدر الإمكان. يتم وضع كل شيء دائمًا على الصفحة ، في شكل هيكل عظمي ، على الأقل. عندما يحتاج التصميم أو التكوين المعين إلى عرضه ، فأنت تجنّب محتوياته ، وعرض هذا الجزء من واجهة المستخدم مع CSS. تعد فئات CSS الحصرية المتبادلة مفيدة لهذا ، أشياء مثل: "المشاريع المفتوحة" ، "المستندات المفتوحة" ، "Out-Open".

Answer 3

أقوم بتصميم نظام إنترانت قائم على الوحدة باستخدام Backbone.js وأنا أستخدم الخوارزمية التالية بشكل أساسي في تحميل المستند.

• إنشاء AppController ، وحدة تحكم Singleton للتطبيق.
• يقوم AppController بإنشاء MainView ، وهذا هو العرض المسؤول عن تقديم الهيكل العظمي للصفحة ومعالجة النقرات للعناصر المستمرة على الصفحة (أزرار تسجيل الدخول/تسجيل الدخول ، إلخ)
• تنشئ MainView عددًا من عمليات الأطفال للأجزاء المختلفة من الصفحة ، والملاحة ، وتفتت الخبز ، والأسمت ، وشريط الأدوات ، و ContentContainer ، وما إلى ذلك. يمكن أن يحتوي المحتوى على وجه الخصوص على أي تصميم.
• يعمل AppController عبر الوحدات المسجلة ، وبدأت MainModuleController لكل منها. كل هذه تحتوي على مخططات توجيه مساحات الأسماء.
• backbone.history.start ()

تمكن ModuleControllers من الوصول إلى AppController على init. عند اللحاق بالموقع التجزوي ، يقومون بإرسال حدث Pagechange إلى AppController يحتوي على كائن PageManifest. يحتوي كائن PageManifest على جميع المعلومات اللازمة لتعيين المشاهدات ذات الصلة ، مثل معلومات فتات الخبز ومعلومات الرأس ، والأهم من ذلك ، إشارة إلى محتوى محدد. يستخدم AppController المعلومات الموجودة في PageManifest لإعداد طرق العرض المختلفة المختلفة ، ويحذف ContentView السابق في ContentContainer وإدراج ContentView المقدم من الوحدة النمطية في الحاوية.

وبهذه الطريقة ، يمكن للمصممين المختلفين العمل على وحدات مختلفة وكل ما يتعين عليهم معرفته هو مواصفات كائن PageManifest وكيف يجب أن يبدو ContentView. يمكنهم إعداد أنظمة توجيه معقدة خاصة بهم ، واستخدام النماذج الخاصة بهم ومحتوى المحتوى المخصص (على الرغم من أننا نخطط للحصول على مكتبة من ListViews ، و ObjectViews ، وما إلى ذلك للوراثة من).

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

Answer 4

أواجه نفس المشكلة بالضبط بغض النظر عن العمود الفقري أو أي إطار/مكتبة JS أخرى.

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

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

قد يحتوي الرأس على طريقة عرض شعار (إذا كان لها وظيفة) وعرض قائمة عالمي/مستخدم. سوف تحتوي المنطقة اليسرى على عرض NAV الأساسي.

ثم تعقيد آخر. يقوم كل رابط داخل عرض NAV الأساسي بتحميل تخطيط فرعي جديد جاهز لمزيد من المشاهدات لضخ نفسه.

لا أريد أن تهتم وحدات التحكم/وجهات النظر العادية بما يتم تقديمه حاليًا ، فقط أن يكون عنصر الحاوية الخاص بهم جاهزًا للحقن فيه.

فكرت في استخدام الطرق (وليس بالمعنى التقليدي) بطريقة ذكية مثل:

function LayoutController() {
App.addRouteMatcher("/sign_in/*", this.renderSignInLayout); // single column
App.addRouteMatcher("regex to represent anything but sign_in", this.renderMainLayout); // header, footer, primary nav, main zone
App.addRouteMatcher("/section1/*", this.renderSubLayoutForSection1); // puts a 1 column layout in the main zone
App.addRouteMatcher("/section2/*", this.renderSubLayoutForSection2); // puts a 2 column layout in the main zone 
}

بمعنى أنه إذا كان المسار "/section1/anha/page/inse/ection/1" تم تشغيل مطابقة المسارين أعلاه "regex لتمثيل أي شيء سوى sign_in" و "/section1/*". سيتم تقديم التصميم ومن ثم سيتم تقديم التخطيط الفرعي Section1 بعد ذلك إذا كان ذلك منطقيًا.

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

يجب أن تكون هناك طريقة لطيفة لإدارة التخطيطات وضمان تلك التخطيطات والتخطيطات الفرعية والآراء بأمان لضمان معالجة تسرب الذاكرة من بين أسباب أخرى.

أحب أن أسمع شخصًا صمم ونفذ شيئًا أنيقًا.