منتدى المستخدمين كثيرا ما وصفه أسئلة من هذا القبيل:
> مرحبا,
>
> من فضلك قل لي ما إذا كان هناك أي إمكانيات لبناء قائمة مخصصة مع
> نوع الرئيسية والتفصيلية (مثل الفواتير) دون استخدام InfoPath.
>
يوفر SharePoint بعض من ميزات مربع التي تدعم أنواع من متطلبات عمل مثل هذا.
بشكل عام, واحد يربط بين قائمتين معا باستخدام عمود بحث. قائمة A يحتوي على معلومات رأس الفاتورة وقائمة ب يحتوي على تفاصيل الفاتورة.
استخدام قوائم إضافية للحفاظ على أرقام العملاء, أرقام المنتجات, إلخ.
استخدم جزء ويب الخاص استعلام المحتوى (في موس فقط) و/أو عرض بيانات جزء ويب إنشاء طرق عرض القوائم المدمجة. خادم SQL خدمات التقارير (استراتيجية الاعتماد على الذات) يتوفر أيضا لجانب الإبلاغ فإنه.
ومع ذلك, هناك بعض القيود الهامة التي سوف تجعل من الصعب على استخدام نقية الخروج من مربع الخصائص لأي شيء حتى متوسط التعقيد. وتشمل هذه:
- حجم البحث ذات الصلة بسرد مقابل. "الذكاء" نوع عمود بحث. نوع عمود بحث يطرح نفسه في واجهة المستخدم بشكل مختلف اعتماداً على ما إذا كنت قد مكنت متعدد حدد أم لا. وفي كلتا الحالتين, الخروج من مربع عنصر التحكم يظهر كافة العناصر المتوفرة من القائمة المصدر. إذا كان القائمة المصدر 1,000 العناصر, أنه ستكون هناك مشكلة. صفحة عنصر تحكم البحث لا من خلال تلك العناصر. وبدلاً من ذلك, أنها تسحب كل منهم في عنصر التحكم. وهذا يجعل لواجهة مستخدم حرج جداً سواء من حيث إدخال البيانات والأداء.
- عمليات البحث "التراجع" عمود واحد للمعلومات. يمكنك ابدأ سحب مرة أخرى من عمود واحد أو أكثر من معلومات من القائمة المصدر. وعلى سبيل المثال, لا يمكنك تحديد عميل "12345" وعرض عدد فضلا عن اسم وعنوان العميل في نفس الوقت. يظهر البحث فقط العميل رقم ولا شيء. وهذا يجعل لواجهة مستخدم محرجا وصعبا.
- لا الاتصالات داخل النموذج. لقد كتبت عن ذلك هنا. لا يمكن تطبيق المنسدلة المتتالية, شروط تمكين/تعطيل الحقول, إلخ.
- لا تتالي الحذف أو التكامل المرجعي المدمج. SharePoint يعامل القوائم المخصصة ككيانات مستقلة ولا تسمح لك بربطها ببعضها البعض في شعور ERD التقليدية. وعلى سبيل المثال, SharePoint تسمح لك بإنشاء قوائم مخصصة اثنين, "العملاء" و "رأس الفاتورة". يمكنك إنشاء عنوان فاتورة الذي يربط العودة إلى أحد العملاء في قائمة العملاء. ثم, يمكنك حذف العميل من القائمة. من خارج منطقة الجزاء, لا توجد طريقة لمنع هذا. لحل هذا النوع من المشاكل, يمكنك عادة استخدام معالجات الأحداث.
قد يبدو قاتما, ولكن أود أن لا يزال استخدام SharePoint كنقطة انطلاق لبناء هذا النوع من الوظائف. على الرغم من أن هناك فجوات بين ما تحتاجه في التوصل إلى حل, SharePoint تمكننا من سد تلك الثغرات باستخدام أدوات مثل:
- معالجات الأحداث. استخدامها لفرض التكامل المرجعي.
- أعمدة مخصصة: إنشاء أنواع أعمدة مخصصة واستخدامها بدلاً من عمود البحث الافتراضية. إضافة الترحيل, جاري وميزات AJAX جعلها تستجيب.
- BDC. تمكن هذه الميزة موس فقط لنا للاستعلام قوائم SharePoint الأخرى مع واجهة مستخدم متفوقة لعمود البحث المعتادة. BDC يمكن الوصول أيضا إلى تطبيق ملقم نهاية الخلفية. استخدام BDC لتجنب تكرار. بدلاً من النسخ المتماثل لمعلومات العميل من خلفية نظام تخطيط موارد المؤسسات, بدلاً من ذلك استخدم BDC. ميزات BDC توفر واجهة مستخدم لطيف لسحب هذه المعلومات مباشرة من نظام تخطيط موارد المؤسسات التي ينتمي فيها والابتعاد عن المتاعب للحفاظ على حل النسخ المتماثل.
BDC سمة من سمات موس (غير متوفر في WSS) ويمثل تحديا لتكوين.
- نموذج ويب ASP.NET: إنشاء كامل المواصفات أياكس تمكين نموذج يستخدم كائن SharePoint services النموذجي و/أو ويب لتحسين قوائم SharePoint مع توفير واجهة مستخدم استجابة للغاية.
الخيار الأخير قد أشعر بأن كنت تبدأ من الصفر, ولكن النظر في حقيقة أن نظام SharePoint الأساسي يبدأ يمكنك مع الميزات الرئيسية التالية:
- نموذج الأمن مع الصيانة.
- نظام القائمة مع الصيانة.
- "الجدول الرئيسي" (الأول-هاء. قوائم مخصصة) مع الأمن, صيانة المدمج والتدقيق.
- البحث.
- أدوات التكامل النهاية الخلفية (BDC).
إذا كنت تبدأ مع مشروع فارغ جديد في visual studio, لديك الكثير من البنية التحتية والسباكة بناء قبل الحصول على مقربة من ما يقدم SharePoint.
وأعتقد أن مايكروسوفت تعتزم توسيع SharePoint في هذا الاتجاه لتطوير التطبيقات. تبدو كما لو أنها امتداد طبيعي للقائمة SharePoint قاعدة. CRM التطبيق في Microsoft يوفر قدرا كبيرا من القابلية لتوسعة الأنواع المطلوبة لدعم تطوير التطبيقات رأس/التفاصيل. وعلى الرغم من هذه الميزات في إدارة علاقات العملاء, التكنولوجيا المتاحة ومن الواضح أن فريق التطوير SharePoint وأتوقع أنه سيجعل طريقها إلى المنتج SharePoint قبل نهاية 2008. إذا كان أي شخص لديه المعرفة أو التبصر في هذا, يرجى ترك تعليق.
</نهاية>
كبيرة
راغو, لا أعتقد أن هناك أي وسيلة سهلة للقيام بذلك. أود أن أركز على التدريب الخاص بك المستخدمين عند استخدام أي واحد منهم وربما تعطي لهم اكتب تلميحاً مع اسم المحتوى نفسه. لا أعتقد أن كنت حقاً مسمار هذا واحد لأسفل, من الناحية التقنية.
أنها قليلاً من حل أهوج لمشكلة ولكن أنا استخدم القائمة منسدلة ASP.Net التي الظلال البحث "القائمة المنسدلة" التي تم إنشاؤها بواسطة SharePoint. وأشير إلى مصدر بيانات استناداً إلى القائمة التي تحتوي على عنصر البحث القائمة المنسدلة ASP.Net, السماح لي باستخدام حقل معرف كالقيمة والعمود من خياري كنص العرض. أنا لا ربط القائمة المنسدلة ASP.Net إلى حقل قائمة "البحث" لأنه يولد أخطاء الخادم.
في صفحة تحميل استخدام جافا سكريبت لتعيين القيمة الصحيحة للقائمة المنسدلة ASP.Net, ومن ثم إرفاق الأحداث onchange لأن القائمة المنسدلة لتعيين قيم جديدة إلى القائمة المنسدلة البحث SharePoint المقابلة. أنا فعلا إخفاء الصف الذي يحتوي على القائمة المنسدلة SharePoint.
شيء واحد آخر — بسبب الطريقة التي يعرض SharePoint dropdowns بحث أبله عندما يحصل على العدد العناصر السابقة 20 أنا استخدم الكائن المجمع المخصص للحصول على/تعيين قيمة القائمة المنسدلة. لدى بلوق وظيفة تفاصيل تلك العملية هنا:
http://www.idiotsyncrasies.com/2007/12/lookup-list-dropdowns-in-sharepoint.aspx
هتاف,
مايكل
يمكنك إنشاء "نوع محتوى" لرأس الفاتورة، استناداً إلى "نوع محتوى المجلد" وثم إنشاء "نوع محتوى" آخر فاتورة وإضافة كل إلى قائمة SharePoint. هذا في الواقع يخلق علاقة الوالد والطفل الذي سوف يسمح لك لإنشاء فواتير متعددة استناداً إلى "نوع محتوى الفاتورة" التي تعيش تحت "رأس الفاتورة نوع المحتوى" الذي يعطي لك وفورية العلاقة بين هذين البندين وإذا "رأس الفاتورة" عنصر قائمة يتم حذف جميع بنود الفاتورة الطفل داخل هذا المجلد سيتم حذف. يمكنك أيضا تحديد أن يكون "نوع المحتوى" متاح من داخل مجلد معين فقط. وهذا النهج مماثلة إلى كيف يعمل مكتبة المناقشة ومفيدة جداً لهذا النوع من العلاقة بين العناصر. معالجات الأحداث والتعليمات البرمجية سوف يساعد مع بعض القيود الأخرى لكن عموما حل سهل السريع.