Jeg arbeider på et prosjekt som bruker fem forskjellige SharePoint Designer arbeidsflyt til å håndtere noen dokumentet godkjenninger. SPD gir "samle data fra en bruker" handlingen slik at vi kan be brukeren om forskjellige informasjonsbiter, som om de godkjenne den, noen kommentarer og kanskje spørre hva de hadde til middag den andre natten.

Skjemaene er perfekt funksjonelle. De er knyttet til en oppgaveliste som en innholdstype. De er 100% systemgenerert. Dette er deres styrke og svakhet. Hvis vi kan leve med standardskjemaet, så er vi gode å gå. Men, Vi har ikke mye kontroll over hvordan SPD oppretter skjemaet. Hvis vi ikke liker denne standardvirkemåten, Vi må ty til ulike triks for å komme rundt det (for eksempel, Angi prioritet for en oppgave).

Jeg måtte gi en link på disse aktivitetsskjemaer som åpnet Visningsegenskaper (DispForm.asxp) av den "relaterte varen" i et nytt vindu. Dette gir Ettklikkstilgang til metadata av den relaterte varen. Dette er hva jeg mener:

Heldigvis, Vi kan gjøre det og det er ikke vanskelig. Stort sett, fyre opp SPD, Naviger til mappen som huser arbeidsflytfilene og åpne ASPX-filen du vil endre. Dette er bare klassiske XSL-transformeringen instruksjoner og hvis du har kastet med itemstyle.xsl, Søk eller andre XSL-scenarier, Dette vil være enkelt for deg. faktisk, Jeg fant det å være generelt enklere siden det genererte skjemaet er noe lettere å følge sammenlignet med en kjerne søkeresultater-webdelen (eller marerittaktige CWQP).

selvfølgelig, Det er en stor fallgruve. Redigeringsprogrammet for SPD arbeidsflyt forventer full kontroll over filen. Hvis du endrer det, SPD lykkelig overskrive din endringer gi høyre sett med omstendigheter. Jeg gjorde to rask tester for å se hvor ille dette kan få. Begge forutsetter at du har laget en gyldig SPD arbeidsflyt som bruker "samle data fra en bruker" Trinn.

Test 1:

• Endre filen ASPX for hånd.
• Test den (Kontroller at endringene var riktig lagret og ikke ødelegge noe).
• Åpne arbeidsflyten og legger til en relatert handling (som "log historie").
• Lagre arbeidsflyten.

Resultatet: I dette tilfellet, SPD ikke gjenopprette skjemaet.

Test 2:

• Gjør det samme som #1 bortsett fra direkte endre "samle data fra en bruker" handling.

Resultatet: Dette oppretter nytt skjema fra bunnen, skrive over endringene.

Siste notater:

• Minst to SPD handlinger oppretter skjemaer som dette: "Samle Data fra en bruker" og "Tilordne til elementet". Begge disse handlingene’ skjemaer kan endres manuelt.
• Jeg kunne generere min link til dispform.aspx fordi, i dette tilfellet, relatere varen har alltid sin ID innebygd i den relaterte varen URL. Jeg klarte å pakke den og deretter bygge en <et href> basert på det å gi funksjonen ett klikk meta data tilgang. Det er usannsynlig at nettadressen følger denne regelen. Det kan være andre måter å få ID av den relaterte varen, men jeg har ikke hatt å krysse denne broen, så jeg ikke vet om får til den andre siden av kløften.
• Jeg undersøke ikke, men jeg ville ikke bli overrasket hvis det er en slags malfil i den 12 strukturen som jeg kunne endre for å påvirke hvordan SPD genererer standardskjemaene (mye som vi kan endre alert maler).

</slutten>

Abonner på bloggen min!