الفاصوليا المغطاة بالطلب وتهيئة datamodel؟

Question

تحديث II:حسنًا ، تمكنت من تضييقها قليلاً.

لديّ صفحة مع بيانات قابلة للتصنيف وتصفية وظائف ، وكلاهما يحدث في DB. بمعنى آخر ، أنا لا أستخدم الوظيفة المدمجة للأثرياء: Datatable التي أستخدمها ، بل دع DB يقوم بالعمل.

انا اعمل مع طلب الطلب فاصوليا. تحتوي الفاصوليا الوحيدة التي تم سكانها للجلسة على فرز وتصفية الواجهة الخاصة بي.

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

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

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

المشكلة هي أن JSF DataTable و DataScroller في صفحتي اتصل على backingBean.getDataModel() التي تجلب البيانات من DB و dataModel.getRowCount() (الذي قمت بتطبيقه لاستدعاء طريقة تدير استعلام منفصل) ايضا أثناء ال تطبيق قيم الطلب مرحلة. يأخذ هذان الاستعلامات أيضًا في مرحلة الاستجابة ، وهي المرحلة الوحيدة التي توجد فيها التغييرات في مكانها ، وسيتم تشغيل الاستعلام بشكل طبيعي.

هذا يعني أنه لإظهار صفحة بعد إجراء التصفية أو الفرز ، يتم إجراء عدد مزدوج من الاستعلامات.

أرغب في تنفيذ الفرز وتصفية إجراء الاستعلامات المطلوبة فقط وليس أكثر.

أي اقتراحات؟

Answer 1

تعد مرحلة Getter Call أثناء تطبيق قيم الطلب إلزامية لأن JSF يحتاج إلى معرفة أي قيم الإدخال التي تم عرضها في البداية بحيث يمكنها في النهاية القيام بأي التحقق و/أو الاتصال بأي Valuechangelisteners في المرحلة التالية عند الاقتضاء. من الضروري أيضًا معرفة الزر/الرابط الذي تم الضغط عليه/النقر عليه في أي من الصفوف بحيث يعرف أي إجراء للاتصال في مرحلة العمل الاستدعاء.

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

لسوء الحظ ، لا يمكنك تعطيله تمامًا. من الناحية الفنية ، فإن اللجوء الوحيد إلى ذلك هو وضع حبة البيانات في نطاق الجلسة وإجراء استعلام SQL باهظ الثمن (وتحديث Datamodel) فقط في مُنشئ الفول وفي طريقة عمل الفول ، بحيث يتم التذرع بها فقط أثناء الفول البناء (للعرض الأول) وخلال طريقة عمل Bean (خلال نوع/مرشح جديد/أي طلب). ومع ذلك ، فإن العيب هو أن أي تغييرات في Datamodel تنعكس في جميع Windows/علامات التبويب التي يفتحها Enduser في نفس الجلسة ، والتي قد تسبب "WTF؟" تجارب للإنذار.

الآن ، كان Tomahawk هو الأول الذي لديه حل لطيف لهذا في نكهة preserveDataModel ميزة ل <t:dataTable>, ، الذي يضع datamodel بشكل أساسي في شجرة المكونات الخاصة بالطلب (والتي بدورها يتم تخزينها بالفعل في نطاق الجلسة أو في حقل إدخال مخفي في جانب العميل ، اعتمادًا على كيفية تكوين موقع المتجر لحالة العرض في الوجوه- التكوين). Richfaces ليس لديه حل مباشر من هذا القبيل ، ولكن <a4j:keepAlive> هل الشيء نفسه في الأساس. سيؤثر ذلك فقط على الفاصوليا "الكاملة" ، وبالتالي إذا كانت حبة البيانات الخاصة بك تحتوي على أكثر من Datamodel فقط ، فقد تفكر في إعادة تجديدها. يجب أن تضع في اعتبارك تصميم الفول كما لو كانت حبة منتقاة الجلسة.

إذا كان Datamodel كبيرًا ، فيمكنني أن أتخيل أن هذا يؤثر على ذاكرة الخادم ، ولكن هذا لا ينبغي أن يؤذي ذلك كثيرًا إذا كنت تخزن فقط يمكن عرضه جزء من datamodel في الذاكرة (وبالتالي ليس بأكمله Datamodel ، بما في ذلك جميع الصفحات الأخرى). معرفة ما إذا كانت تفوق تكلفة إطلاق استعلامات SQL المزدوجة أثناء طلب HTTP واحد.

أتمنى أن يساعدك هذا.