bRahms zei:
- Wat zijn jouw ervaringen met MOSS
- Zijn er die eventueel ervaring hebben met Sharepoint Portal Server en die de vergelijking kunnen maken met MOSS?
- Wat te zeggen van de standaardfuncties zoals [Today] en [Me] in MOSS?
- Wat te zeggen van Sharepoint Designer, zijn geld waard of totaal niet?
- Is er een goede integratie met andere office programma's (Word, Excel, InfoPath)?
Ik heb ondertussen 2 jaar ervaring (development, configuration) met SharePoint 2003, en SharePoint 2007 sinds Beta2. De 2007 is een echte verademing tegenover de vorige versie. Dit zowel voor eindgebruikers als voor developers (dit laatste merk ik in mijn dagdagelijkse taken het vaakst).
In deze versie ontbreken nog veel (logische) zaken, maar als developer heb je tenminste de kans om ze te ontwerpen. De vorige versie liet dit niet altijd toe, gewoon omdat de werking zo specifiek/beperkend was.
Nu heb je de volledige .NET 2.0 mogelijkheden tot je beschikking.
SharePoint 2003 bestond uit twee verschillende technologieën, dit is samengetrokken met SP2007: Office SharePoint Server is een uitbreiding van SharePoint Services die geactiveerd of gedeactiveerd kan worden per site.
In MOSS2007 zit nu ook CMS2002 voor je Publishing. Jammer genoeg is dit niet zo handig uitgewerkt als ze willen doen lijken. Als je tweetaligheid probeert in te voeren via Variations kom je al snel tot enkele harde beperkingen; het geldt immers enkel voor pagina's (Article Pages, Welcome Pages) en niet voor gewone SharePoint Lists. Klinkt misschien logisch maar niet altijd even verkoopbaar aan klanten die volledige tweetaligheid verwachten.
Ben ondertussen al op enkele lastige en zeer lastige bugs gestoten. Voor de meeste zaken kan je wel een work-around developen, maar dit is niet echt de ideale situatie. Dit is niet zozeer een nadeel van SharePoint, maar meer van de time to market strategie van Microsoft en meer en meer op Service Packs rekenen.
SharePoint Designer is zeker zijn geld waard. Je kan master pages, page layouts, en dergelijke ook wel met Notepad, Visual Studio of een andere editor bewerken, maar de integratie met SharePoint (waar alle content in SQL zit) is toch wel een voordeel. Al heeft SPD zelf ook wel enkele lastige bugs en probeer ik die zo min mogelijk te gebruiken. Meestal heb ik een testsite in SharePoint die ik met SPD aanpas en de live sites pas ik dan via Visual Studio aan. Dit is omdat SPD in sommige gevallen relatieve urls om zeep helpt.
Integratie met client Office zit wel goed voor het grootste deel; d.i. de algemene werking voor een doorsnee gebruiker. Wel jammer dat ze Excel functionaliteit voor geëxporteerde lijsten weggehaald hebben: in SP2003 en Excel 2003 had je 2-way updating van een SharePoint Lijst die naar Excel geëxporteerd had.
InfoPath is nu belangrijker geworden; naast de standaard data collection wordt die nu ook gebruikt om MOSS 2007 workflow schermen aan te maken die in de browser getoond worden via Forms Server. En als je echt wil toveren kan je de Word Document Property Pane aanpassen naar je eigen InfoPath formulier en er validatie en data sources insteken.
=======================================
bRahms zei:
- de [Today]-functie is een functie die gebruikt kan worden om de datum van vandaag weer te geven. Doch heeft deze functie enkel nare bijwerkingen. Zo zal hij bij de creatie van een document inderdaad de datum van vandaag weergeven, maar morgen zal hij nog steeds de datum van vandaag weergeven. Dit kan (belachelijk) opgelost worden door opnieuw een Single line of text - column Today aan te maken en direct (!) erna opnieuw te verwijderen. Dan wordt de datum die opgeslagen staat in een kolom (die je best niet al te zichtbaar maakt) omgezet naar die van vandaag. Zit je echter met een beperkt aantal documenten, dan kan je ook deze openen en opslaan zonder iets (verplicht) daaraan te wijzigen.
VRAAG: Moest er iemand een andere, mindere omslachtige manier weten om dit, toch wel vervelend punt binnen WSS, op te lossen. Gelieve het me te vermelden. Je hoeft daarbij zeker niet af te komen met oplossingen van Sharepointblog's, want ik vrees dat ik zowat alle vooropgestelde zaken geprobeerd heb, zonder enig succes.
- Bij document-indexering, en dit bij integratie Infopath-WSS, ben ik op een wel heel vreemd geval gestoten. Ik had in m'n formulier meegegeven dat hij in een veld het laatste ID moest weergeven van de Sharepoint-library en daarbij 1 moest optellen ((max(@ID) +1), waarbij de @ verwijst naar de secundaire gegevensbron van de library). Dit werkt, zoals ik ook had gedacht, perfect... TOT je in de toekomst datum's begint mee te geven die ook moeten worden opgeslagen in de library. Neem nu het volgende.
-> WSS:
1 ... doc1 ... 14/04/2007
2 ... doc2 ... 19/04/2007
--> InfoPath: ID: 3, de datum dat we meegeven is 05/05/2007.
We dienen het formulier in en zien in WSS:
1 ... doc1 ... 14/04/2007
2 ... doc2 ... 19/04/2007
3 ... doc3 ... 05/05/2007
So far so good, maar bij de creatie van een volgend document binnen Infopath zie je het volgende staan: ID: 3. Na veelvuldig te hebben gezocht en zelf te hebben getest bleek dus dat je geen datum in de toekomst kon meegeven. Sharepoint zal, indien je dit toegelaten hebt in Infopath, dit document wel nog opslaan, maar niet onder ID: 4, maar onder ID 3, overgeschreven.
VRAAG: Is dit oplossbaar zodat dit ook met toekomstdatums werkt?
- Klopt het dat je niet tegelijkertijd met twee personen in Infopath kunt werken via Sharepoint? Dat de een het document kan aanpassen, en de ander gewoon het formulier kan raadplegen, zonder de wijzingen die hij aangebracht heeft, kan wegschrijven naar de library?
VRAAG: Indien ja, is er ook hier een omweg voor?
- In de library heb je ook de mogelijkheid om Group-by te doen? Daarbij telt hij het aantal rijen dat in de kolom ingevuld zijn. Is er ook een mogelijkheid binnen WSS om de waarde op te tellen die in de rijen staat (number)
Dus bv:
1 ... doc1 ... 14/04/2007 ... 4
2 ... doc2 ... 19/04/2007 ... 5
3 ... doc3 ... 05/05/2007 ... 9
Total: 3 (Deze drie zou moeten kunnen vervangen worden door 18)
- In WSS hebben we ook een zelfgemaakte agenda gemaakt, die de uren bijhoudt per dag. Is er binnen Sharepoint Services een controle mogelijk die er op toeziet dat:
* de einduren groter moeten zijn dan de starturen,
* de uren elkaar niet kunnen overlappen.
Ik ben er in ieder geval wel al ingeslaagd om het verschil te bereken (via de standaard HOUR functie) tussen het begin- en einduur. Maar dan, aan de agenda zijn er ook documenten gekoppeld die bijhoudt aan welk document je gewerkt heb op dat moment. Is er een mogelijkheid om dit calculated veld te laten invullen in Sharepoint Services, aan de hand van de ingelogde gebruiker?
Dit zijn zowat de eerste paar zaken die me direct tebinnen schoten bij het openen van m'n sharepointsite.
* [TODAY] werkt zoals verwacht, dat zijn geen bijwerkingen. De bedoeling van TODAY is dat je de documenten van de laatste 7 days toont, of contacts die vandaag verjaren (TODAY = BIRTHDAY).
* Je InfoPath-WSS probleem is me niet duidelijk. Wat probeer je te bereiken ?
Afhankelijk van wat je wil bereiken kan je de Created Date in je formule gebruiken of een Event Handler schrijven.
* Met meerdere personen werken aan een InfoPath formulier werken is geen moeilijkheid. Als iemand het formulier aan het bewerken is, krijgt de ander de vraag om een Read-Only copy te openen om te bezichtigen.
* Je kan de lijst openen als Datasheet (Edit in DataSheet) en dan de totalen zien. Wanneer je weer terugswitcht naar standaard view blijven de totalen zichtbaar
* Standaard kan je geen validaties doen tussen verschillende kolommen (beginuur, einduur). Een kolom afhankelijk van de ingelogde gebruiker is ook niet mogelijk met de standaard functionaliteit. Je kan hiervoor wel een eigen kolomtype maken (via development), maar dit vergt wel een goede (programmeer) kennis.
Conclusie:
SharePoint is een ontzettend uitgebreid product. Je kan er heel veel mee, maar je kan er zeker niet alles mee. In praktijk komt het heel vaak neer om wat water bij de wijn te doen en sommige wensen te laten vallen of custom development te doen.
SharePoint is een generiek product en een klant heeft specifieke eisen. De kracht van SharePoint tegenover een custom product (volledig op maat gemaakt voor de klant) is dat je al een heel brede basis hebt om je intranet of website op te zetten met document collaboration, security mechanismes, search, taken, discussies, etc. Als je echt specifieke zaken wil zal je moeten developen.
HTH,
Steven
