XsltListViewWebPart ينسى الويب الحالي عند عرضه على صفحة التخطيطات

sharepoint.stackexchange https://sharepoint.stackexchange.com//questions/40750

سؤال

أقوم بإضافة بسيطة جداً XsltListViewWebPart إلى صفحة التطبيق.مثل ذلك:

XsltListViewWebPart lvWebPart = new XsltListViewWebPart { ChromeType = PartChromeType.None, ListUrl = "/somesite/list" };
Page.Controls.Add(lvWebPart);

كل شيء يعمل بشكل جيد (يمكنني تنزيل الملفات، وإنشاء المجلدات، واختيار طرق عرض مختلفة، وما إلى ذلك) - ولكن روابط المجلدات تحتوي على href غير صحيح:يشيرون دائمًا إلى شبكة الجذر!

انظر هذه الأمثلة:enter image description here

كما ترون، يرتبط المستند بشكل صحيح بـ ../sites/sr/doclib/mydocument.docx ولكن عند النظر إلى المجلدات، ينسون السياق الموجود حاليًا (هم موجودون في http://../sites/sr/_layouts/../../..Detail.aspx?RootFolder=..., ، الجزء المهم هو /sites/sr/).يحاولون الانتقال إلى المجلد _layouts في سياق مجموعة الموقع الجذر - كما هو موضح أعلاه: http://../_layouts/../../..Detail.aspx?RootFolder=...

أو تلخيصها مرة أخرى:

  • موقع صفحة التطبيق:
    • http://sp/sites/sr/_layouts/my/application/Detail.aspx
  • القائمة/doclib التي أقوم بالوصول إليها
    • http://sp/sites/sr/mylist
  • عنوان URL للمجلدات الموجودة داخل XsltListViewWebPart
    • http://sp/_layouts/my/application/Detail.aspx?RootFolder=...
  • عنوان URL للمجلدات كما ينبغي أن يكون
    • http://sp/sites/sr/_layouts/my/application/Detail.aspx?RootFolder=...

هنا يأتي كيكر:عند استخدام أ ListViewWebPart, ، كل شيء يعمل كما ينبغي!لذلك بدلاً من XsltListViewWebPart أعلاه، أستخدم فقط ListViewWebpart - وتعمل المجلدات، ويتم أخذ السياق في الاعتبار حيث تحتوي المجلدات على عنوان URL كما أريد (http://../sites/sr/_layouts/../../..Detail.aspx?RootFolder=...

حاولت ضبط معرف الويب الملكية الموجودة على XsltListViewWebpart تأمل أن تحدد السياق، ولكن لم يحالفها الحظ.أعتقد الآن أنني إما قمت بتكوينه بشكل خاطئ أو أن SharePoint 2010 XsltListViewWebPart الجديد به خطأ - حيث يعمل نفس الرمز مع ListViewWebPart في نفس صفحة التطبيق.

آمل أن يتمكن شخص ما من التحقق من هذه المشكلة.

هل كانت مفيدة؟

المحلول

باختصار، لا تستخدم XsltListWebPart على صفحات التطبيق.

وإليك بعض التوضيحات المختصرة:

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

يمكن تأكيد ذلك بشكل غير مباشر من خلال قراءة مقالات MSDN التالية على الأقل:

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

كما جاء ذلك في دورة MS 10232.

فيما يتعلق بـ XsltListViewWebPart (XLV) على وجه الخصوص، سمعت عن مشكلات متعددة أثناء استخدامه من صفحة التطبيق، وواجهت بعضًا منها بنفسي.

على سبيل المثال، إذا قمت بتخصيص XLV باستخدام خاصية XslLink، فسيفشل XLV في تخزين ملف xsl مؤقتًا، ونتيجة لذلك، لن تعمل ECB والأزرار المقابلة على الشريط.في السجلات، سوف تحصل على رسالة الاستثناء التالية:

جرت محاولة استخدام كائن لم يعد موجودًا.

يمكنك أيضًا مراجعة السؤال التالي للحصول على مثال آخر لمشكلات جزء ويب OOTB على صفحة التطبيق (ListViewWebPart، هذه المرة):

نصائح أخرى

أولاً، أعتقد أن أندريه ضرب المسمار في رأسه.وبالإضافة إلى ذلك، يمكنك محاولة استخدام التحكم في ListViewByQuery في صفحة التطبيق إذا كنت تبحث عن تخطيط جدولي بسيط للبيانات (أيقائمة).تقوم Microsoft بذلك في صفحة حالة سير عمل OOB (أي._layouts/wrkstat.aspx) لعرض المهام.

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

إذا اخترت ListViewByQuery، فتأكد من مراجعة هذه الروابط للترحيل، وما إلى ذلك:

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى sharepoint.stackexchange
scroll top