جافا ويب التطبيق تزيين يشمل القضايا

Question

الخلفية:لدينا نظام كان مكتوب في السن CMS على أساس جافا مرة أخرى خلال الفترة 2002-2003 أيام.نحن نريد أن نواصل المضي قدما مع الاشياء الجديدة باستخدام هر, المشارب, و sitemesh.لدينا الملاحة, تخطيطات, "القرون", js, css, الخ, التي أخذناها من العمر CMS إلى عدد قليل من تطبيقات جديدة لذلك علينا متناسقة الشكل والمظهر.

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

أفضل وصلنا حتى الآن هو جعل حد القياسية sitemesh الديكور ، التي تستخدم ج:استيراد للحصول على ما يحتاج إليه ، المقابس ذلك الحق في.هذا الحل لديه بعض النفقات العامة الشبكة التي يمكن أن تعثر عليه و أعرض تفشل نقطة.لقد بحثت في <%@ include file="/شيء.jsp" %> كذلك ولكن يبدو أن الإطار الوحيد النسبية.يمكننا استخدام ج:استيراد نقطة في المضيف المحلي ، والتي يبدو أن أفضل حل حتى الآن.

هل هناك أخرى النموذجيه/تزيين أطر هناك (البلاط؟) التي يمكن أن تجعل هذا أبسط ؟ ما الذي ينقصنا ؟

Answer 1

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

إذا كان هذا هو سؤالك أود أن أقترح أن تحافظ على الموارد المشتركة في ملفات jar.هذا يتيح لك العديد من المزايا:

1. الخاص بك الموارد المحلية - لا شبكة علوية
2. لديك السيطرة على تحديثات الموارد.

مثال رقم 2:يمكنك الاحتفاظ الخاص بك المشتركة تخطيطات الصفحة في page-layouts-1.x.jar.يمكنك الحفاظ على جعل طفيفة الإصدارات من تخطيطات الصفحة التي لا تؤثر على التطبيقات باستخدام ذلك - فهي قطرة في بدائل.يوم واحد قررت إعادة تصميم التطبيقات الخاصة بك تماما والافراج عن page-layouts-2.0.jar.هذا يتطلب بعض كتابة إلى تطبيقات استخدامه.الآن, إذا كانت تطبيقات حزم تخطيطات الصفحة, بدلا من إبقائها في فئة المشتركة محمل على الملقم يهاجرون إلى 2.0 تخطيط ليست كل شيء أو لا شيء شأنا.يمكنك ترحيل التطبيق في وقت واحد استخدام 2.0 تخطيط ، في حين أن البعض الآخر لا يزال استخدام 1.× التخطيط.

ونحن نفعل ذلك بنجاح كبير باستخدام JSF و Facelets.

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

آمل أن يساعد

Answer 2

ولقد استخدمنا Sitemesh لسنوات، ولدي مشاعر مختلطة حول هذا الموضوع.

وأنا الآن تفضل الكتابة القياسية JSP العلامة الملفات (.tag أو .tagx) إلى استخدام applydecorator. أعتقد العلامة applydecorator ملغى بشكل فعال مع ظهور الملفات العلامة، ولكن لم الكثير من المستخدمين Sitemesh لا تلاحظ.

وكلها تقريبا من استخدام Sitemesh لدينا كان من هذا النوع. سيكون لدينا عدد قليل من قوالب الصفحات المشتركة، أن صفحات JSP سيكون لدينا تشير إلى صراحة تخطيط. "استخدام تخطيط قياسي، وهنا قائمة التنقل وهنا في نص الصفحة." ملفات العلامة هي نسخة مطابقة من هذه الوظيفة، ولكنها موحدة، معتمدة من قبل أي أداة على شبكة الإنترنت J2EE، والمدمج في الحاوية بدلا من الاعتماد آخر.

لتزيين حقا صفحة، حيث صفحة JSP نفسها لا تشير على الإطلاق إلى Sitemesh، وأعتقد أنه من المنطقي على مستوى عال، ولكن ما زلت لا أحب أن صفحة كاملة يتم تحليل مرة أخرى.

وهذه المشكلة الثانية ليست خطأ Sitemesh في الحقيقة. نظرا لAPI بريمج لديها للعمل مع، وأنا لا أعرف ماذا يمكن أن تفعل. لكنها لا تجعل لي أتساءل عما إذا كان البديل القائم DOM-إلى API بريمج القائم على تيار يمكن أن تكون ذات قيمة. وبعبارة أخرى، بدلا من الاضطرار السيرفلتس إرسال إنتاجهم إلى دفق، ما إذا أضافوا العقد إلى شجرة؟ وهذا من شأنه فرض الانتاج بشكل جيد، وجعلها أرخص للقيام التحولات الهيكلية مثل Sitemesh يفعل، أو ترميز الإخراج إلى صيغ مختلفة مثل XHTML، HTML، أو JSON على الطاير.