Forumgebruikers vaak als vragen als deze:

> Hallo,
>
> Vertel me als er zijn mogelijkheden om te bouwen van een aangepaste lijst met
> hoofd- en detailpagina type (Als facturen) zonder het gebruik van InfoPath.
>

SharePoint biedt een aantal uit het vak functies die soorten zakelijke vereisten als dat ondersteunen.

In het algemeen, een verbindt twee lijsten samen met behulp van een opzoekkolom. Lijst A bevat de factuur header-informatie en lijst B Factuurdetails.

Aanvullende lijsten te handhaven klantnummers gebruiken, productnummers, etc.

Een webonderdeel Inhoudsquery gebruiken (in MOSS alleen) en/of een gegevensweergave webonderdeel om samengevoegde weergaven van de lijsten te maken. SQL Server Reporting Services (SRS) is ook beschikbaar voor de rapportage kant van het.

Echter, Er zijn enkele belangrijke beperkingen die het gebruik van pure out-of-the-box functies voor iets dat is zelfs matig complexe moeilijk zal maken. Deze omvatten:

• Grootte van verwante lookup lijsten vs. "intelligentie" van het type van de kolom opzoeken. Een type van de kolom opzoeken presenteert zich op de UI anders afhankelijk van of u meerdere selecteren hebt ingeschakeld of niet. In beide gevallen, de out-of-the-box controle toont alle beschikbare items vanuit de bronlijst. Als de bronlijst 1,000 items, dat gaat een probleem. De lookup-besturingselement doet niet pagina door deze items. In plaats daarvan, het trekt ze allemaal in het besturingselement. Dat maakt voor een zeer lastige user interface zowel in termen van gegevensinvoer en prestaties.
• Zoekacties "pull terug" een kolom met gegevens. U kunt nooit meer dan één kolom met gegevens uit de bronlijst terugtrekken. Bijvoorbeeld, u kunt een klant "12345 niet selecteren" en het aantal, alsmede de naam en adres van de klant weer te geven op hetzelfde moment. De zoekopdracht alleen blijkt de klant nummer en niets anders. Dit zorgt voor een lastig en moeilijk user interface.
• Geen communicatie intra-formulier. Ik heb geschreven over dit hier. U kan niet implementeren cascading drop-downs, voorwaardelijk inschakelen/uitschakelen velden, etc.
• Geen trapsgewijze verwijderingen of ingebouwde referentiële integriteit. SharePoint behandelt aangepaste lijsten als onafhankelijke entiteiten en staat niet toe dat u hen aan elkaar te koppelen in een traditionele ERD zin. Bijvoorbeeld, SharePoint kunt u twee aangepaste lijsten maken, "klant" en "factuurkop". U kunt een factuurkop die links terug naar een klant in het Klantenoverzicht. Vervolgens, u kunt de klant uit de lijst verwijderen. Out of the box, Er is geen manier om dit te voorkomen. Om op te lossen van dit soort problemen, normaal zou u gebeurtenis-handlers gebruiken.

Het lijkt misschien somber, maar ik zou nog steeds SharePoint gebruiken als een beginpunt voor het bouwen van dit soort functionaliteit. Hoewel er verschillen zijn tussen wat je nodig hebt in een oplossing, SharePoint laat ons die met behulp van tools zoals leemten aan te vullen:

• Gebeurtenis-handlers. Ze gebruiken om referentiële integriteit afdwingen.
• Aangepaste kolommen: Aangepaste kolomtypen maken en ze te gebruiken in plaats van de standaard opzoekkolom. Toevoegen van wisselbestand, bufferen en AJAX functies waarmee ze responsieve.
• BDC. Deze functie alleen-MOSS stelt ons in staat om query die andere SharePoint-met een superieure gebruikersinterface aan de gebruikelijke opzoekkolom lijsten. BDC kan ook bereiken om een back-end server-toepassing. Gebruik de BDC om te voorkomen dat replicatie. In plaats van klantgegevens repliceren vanaf een back-end ERP-systeem, BDC gebruiken. BDC-functies bieden een aardig gebruikersinterface te trekken die informatie rechtstreeks vanuit het ERP systeem waar het behoort en vermijdt het gedoe van de handhaving van een replicatieoplossing.

  BDC is een functie van MOSS (niet beschikbaar in WSS) en het is uitdagend om te configureren.

• ASP.NET webformulier: Een full-featured AJAX-enabled formulier maken dat de SharePoint object model en/of web services wordt gebruikt om de invloed van SharePoint-lijsten en biedt een zeer responsieve gebruikersinterface.

De laatste optie kan het gevoel dat je van kras begint, maar rekening met het feit dat het SharePoint-platform u met de volgende kenmerken begint:

• Beveiligingsmodel met onderhoud.
• Menusysteem met onderhoud.
• "Master tabel" (dwz. aangepaste lijsten) met beveiliging, ingebouwde onderhoud en controle van jaarrekeningen.
• Zoek.
• Back-end integratie tools (BDC).

Als u in visual studio met een nieuw, leeg project starten, je hebt een heleboel infrastructuur en sanitair te bouwen voordat u krijgen dicht bij wat SharePoint biedt.

Ik geloof dat Microsoft van plan is om uit te breiden van SharePoint in deze richting van applicatie-ontwikkeling. Het schijnt als een natuurlijke uitbreiding van de bestaande SharePoint base. De Microsoft CRM-toepassing biedt een grote hoeveelheid uitbreidbaarheid van de typen ter ondersteuning van kop-/ detailsectie toepassingsontwikkeling. Hoewel deze functies in CRM zijn, de technologie is uiteraard beschikbaar voor de SharePoint-ontwikkelteam en ik verwacht dat het zijn weg naar het SharePoint-product eind maken zal 2008. Als iemand een kennis of inzicht in dit heeft, laat alstublieft een reactie.

</einde>