Jdbi: تثبيط دعم StringTemplate4 وإيقافه

لنبدأ بإشعار في المستندات أن مشروع StringTemplate غير نشط.

سأترك أعضاء المشروع الآخرين يفكرون في مسألة إهمال تكامل Jdbi ST. أنا شخصياً أعتقد أننا يجب أن نستمر في دعمها لفترة قصيرة على الأقل. لقد بدأنا للتو في دعم ST4 في المقام الأول.

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

دعونا نضيف NOTICE الآن. يمكننا إهمالها بمجرد أن يكون لدينا بديل قابل للتطبيق.

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

شكرًا jarlah ، كان هذا نوعًا مما توقعته.

إنه لأمر مؤسف أن يتم إهمال StringTemplate في المراحل الأولى ، ولكن طالما أن الناس يستخدمونه ويعمل ، فلا يوجد سبب لنا لسحب الدعم.

لقد كنا سعداء للغاية مع FreeMarker حيث أعمل. الشارب هو خيار جيد أيضًا.

أتفق مع jarlah - هناك حاجة إلى بديل. أنا أيضًا أستخدم القوالب بنشاط وستكون النسخ ضخمة بدون ST. يجب أن يكون البديل بسيطًا ومعبّرًا - ما أحبه في ST الحالية. لقد استخدمت Freemarker منذ وقت طويل ، وإذا كنت أتذكره بشكل صحيح - فهو لا يبدو بسيطًا بالنسبة إلى قوالب SQL.

راجع للشغل هنا مشكلتي الأخيرة مع ST ، فهل يمكنني نشرها هنا برمز حل على مستوى تكامل jdbi؟

إذا كان هناك حل بسيط يمكن أن يفعله jdbi دون تعقيد الأمور كثيرًا ، فسننظر فيه بالتأكيد.

كيف يمكن تجميع محركات القوالب الإضافية في Jdbi؟ كلهم يجلبون التبعيات الخارجية التي لا نريدها في core ، ولا نصنع وحدة من فئة 1 ولا نضبط \

حصل قالب سلسلة IIRC على وحدة mvn الخاصة به على الرغم من ذلك ، فربما يجب علينا الاستمرار في فعل ذلك؟ يبدو أنه أقل صعوبة للمستخدمين من التبعيات الاختيارية على أي حال.

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

إذا كانت فئة واحدة قائمة بذاتها مع تبعية واحدة <optional> ، أو خفيفة الوزن بالمثل ، فيمكن أن تدخل في النواة. وإلا فلنقم بتدوير وحدة. كان من المفترض أن يكون تفضيلي بمثابة دليل ، وليس عائقًا مستحيلًا لتجاوزه :)

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

أرى أن قالب السلسلة حصل على @UseStringTemplateEngine على الرغم من وجود @UseTemplateEngine . هل هذا شيء ملائم مرغوب فيه لكل محرك قالب أم أننا نفضل فقط الالتزام بالتعليق التوضيحي العام فقط من الآن فصاعدًا ما لم يكن ذلك ضروريًا؟

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

لقد عملت مع freemarker كثيرًا في الماضي. يمكن أن يكون وسيلة ممتعة لتنفيذ الدعم لها. لا يعني ذلك بشكل مباشر. لكن هذا ممكن. يجب أن نلقي نظرة جيدة على الأداء.

يمكنني أن أقوم برفعها إذا لم يكن هناك شيء آخر

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

أعتقد أن الموقف الذي أدى إلى هذه المشكلة هو مزيج مما يلي:

• يعمل StringTemplate 4 بشكل عام بشكل جيد للغاية (يمكن التنبؤ به إذا لم يكن هناك شيء آخر) في الاستخدام ذي الخيوط الواحدة
• لم يتم تصميم StringTemplate 4 مع التركيز بشكل خاص على الاستخدام المتزامن ، مما أدى إلى أخطاء يصعب حلها دون كسر المستخدمين الحاليين ، لذلك ظلوا في الغالب كما كانوا

إذا تم إنشاء StringTemplate 5 ، أتوقع أن يلعب التزامن الآمن (ومن المحتمل ثباته) دورًا كبيرًا في التصميم الأساسي.