Форум на потребителите често като въпроси като този:
> Здравейте,
>
> Моля, кажете ми ако има всякакви възможности за изграждане на потребителски списък с
> образец и детайл тип (като фактури) без използването на InfoPath.
>
SharePoint осигурява някои от функциите на кутия, които поддържат видове бизнес изисквания като че.
Като цяло, един връзки два списъка, заедно с използване на справочна колона. Списък А съдържа информация за заглавния блок на фактурата и списък Б съдържа информация за фактура.
Използвайте допълнителни списъци, за да запази номера на клиенти, продукти с номера, н.
Използвайте уеб компонент на заявка за съдържание (в мъх само) и/или данни за преглед в уеб компонента за създаване на обединени изгледи на списъци. SQL Server услуги за отчетност (SRS) е също наличен за докладване от страна на това.
Въпреки това, има някои важни ограничения, които ще го направи трудно да се използва чист вън на на кутия възможности за всичко, което е дори умерено сложна. Те включват:
- Размер на свързаните lookup списъци срещу. "интелигентност" от справочен тип колона. Справка колоната тип се представя на потребителския интерфейс по различен начин в зависимост от това дали сте активирали многократен избор или не. И в двата случая, контролата за вън на на кутия показва всички налични елементи от списъка на източника. Ако списъкът източник има 1,000 елементи, Това ще бъде проблем. Контрола за справка не страница през тези елементи. Вместо това, всички от тях дърпа в контрола. Това прави за много неудобно потребителски интерфейс за въвеждане на данни и изпълнение.
- Заявки "дърпам обратно" една колона информация. Вие никога не може да тегли обратно повече от една колона на информация от списъка източник. Например, не можете да изберете даден клиент "12345" и покажете номера, както и името и адреса на клиента в същото време. Търсене само показва на клиента номера и нищо друго. Това прави за неудобно и трудно потребителски интерфейс.
- Intra-форма комуникация. Аз съм писал за това тук. Вие не може да реализира каскадни падащите, условно разрешаване/забраняване на полета, н.
- Без каскадно изтриване или вградени целостта. SharePoint третира потребителски списъци като независими образувания и не ви позволяват да ги свържете помежду си в традиционния смисъл на ERD. За пример, SharePoint ви позволява да създадете две потребителски списъци, "клиент" и "фактура заглавка". Можете да създадете заглавен блок на фактура която свързва обратно към клиент в списъка на клиенти. След това, Можете да изтриете клиента от списъка. На кутията, няма начин да се предотврати това. За решаване на този род на проблема, Вие обикновено ще използвате манипулатори на събития.
Тя може да изглежда мрачна, но все пак ще използва SharePoint като отправна точка за изграждане на този вид на функционалност. Въпреки, че съществуват различия между това, което трябва в разтвор, SharePoint ни дава възможност да попълни тези пропуски, като се използват инструменти като:
Последният вариант може да се чувствате като сте се започне от нулата, Но предвид факта, че платформата SharePoint ти започва със следните основни характеристики:
- Модел на сигурност с поддръжка.
- Менюто система с поддръжка.
- "Главната таблица" (т.е.. потребителски списъци) със сигурност, вградена поддръжка и проверка.
- Търсене.
- Инструменти за интегриране на задния край (BDC).
Ако започнете с нов празен проект в visual studio, имате много на инфраструктура и ВиК да изгради преди да стигнем до това, което SharePoint предлага.
Аз вярвам, че Microsoft възнамерява да разшири SharePoint в тази посока на разработка на приложения. Тя изглежда като естествено продължение на база съществуващата SharePoint. На Microsoft CRM приложение осигурява голяма част от разширяване на типовете, необходими да подкрепят горен/детайл приложение развитие. Въпреки че тези функции са в CRM, технологията е очевидно наличен на SharePoint развитие екип и аз очаквам, че ще направи своя път в SharePoint продукт от края на 2008. Ако някой има знания или вникване в това, Моля, оставете коментар.
</край>