I’m working on a project that uses five different SharePoint Designer work flows to handle some document approvals. SPD provides the "collect data from a user" aksie, sodat ons kan die gebruiker gevra word vir verskillende stukkies inligting, soos of hulle dit goedkeur nie, 'n paar opmerkings en miskien vra wat hulle vir aandete gehad het die ander aand.

The forms are perfectly functional. They are tied to a task list as a content type. Hulle is 100% system-generated. This is their strength and weakness. If we can live with the default form, then we’re good to go. Egter, we don’t have too much control over how SPD creates the form. If we don’t like that default behavior, ons moet die verskillende truuks te kry om dit (byvoorbeeld, stel van voorkeur op 'n taak).

Ek moes 'n skakel op hierdie taak vorms wat die oog eiendomme oopgemaak om voorsiening te maak (dispform.asxp) van die "verwante item" in a new window. This provides one-click access to the meta data of the related item. This is what I mean:

Gelukkig, we can do that and it’s not very hard. Broadly speaking, vuur op SPD, navigate to the directory that houses the workflow files and open the ASPX file you want to modify. These are just classic XSL transform instructions and if you’ve mucked about with itemstyle.xsl, soek-of ander XSL-scenario's, this will be easy for you. In werklikheid, Ek het dit algemeen makliker te wees sedert die vorm wat gegenereer is ietwat makliker om te volg as in vergelyking met 'n soektog kern resultate web deel (of die nagmerrie CWQP).

Natuurlik, there is one major pitfall. SPD’s workflow editor expects full control over that file. If you modify it, SPD will happily overwrite your changes give the right set of circumstances. I did two quick tests to see how bad this could get. They both presuppose that you’ve crafted a valid SPD workflow that uses the "collect data from a user" stap.

Toets 1:

• Verander die ASPX lêer met die hand.
• Toets dit (seker dat jou veranderings is gered en het nie breek nie).
• Maak die workflow en voeg 'n onverwante aksie (soos "teken in die geskiedenis").
• Stoor die workflow.

Uitslag: In hierdie geval, SPD het nie her-skep die vorm.

Toets 2:

• Doen dieselfde as #1 behalwe direk verander die data in te samel van 'n gebruiker" aksie.

Uitslag: Hierdie her-skep die vorm van nuuts af, Oormekaarskryf jou veranderinge.

Finale Notes:

• Ten minste twee SPD aksies skep vorms soos hierdie: "Versamel data van 'n gebruiker" and "Assign To Do Item". Both of these actions’ vorms kan met die hand verander word.
• Ek was in staat om my skakel tot dispform.aspx te genereer, want, in hierdie geval, the relate item always has its ID embedded in the related item’s URL. I was able to extract it and then build an <a href> based on it to provide the one-click meta data access feature. It’s unlikely that your URL follows this rule. There may be other ways to get the ID of the related item but I have not had to cross that bridge, so ek weet nie of kry aan die ander kant van die kloof.
• Ek het nie ondersoek, maar ek sal nie verbaas wees as daar is 'n soort van template lêer in die 12 korf wat ek kon verander om te beïnvloed hoe SPD die standaard vorms genereer (baie soos ons wakker templates kan verander).

</einde>

Skryf in op my blog!