Es esmu strādā pie projekta, kas izmanto piecas dažādas SharePoint Designer darba plūsmas rīkoties daži dokumenta apstiprinājumu. SPD sniedz "savākt datus no lietotāja" darbību, lai mēs varētu aicināt dažādas informācijas apjomiem, ar, piemēram, vai viņi to apstiprināt, dažas piezīmes un varbūt lūgt to, ko viņi bija vakariņas tovakar.

Veidlapas ir pilnīgi funkcionālu. Tie ir saistīti ar uzdevumu saraksta satura tipu. Tie ir 100% sistēmas ģenerēti. Tas ir viņu spēks un vājums. Ja mēs varam dzīvot ar noklusējuma veidlapu, tad mēs esam labi iet. Tomēr, mums nav pārāk daudz kontrolēt kā VPD izveido veidlapu. Ja mums nepatīk, ka pēc noklusējuma, mums ir nepieciešams izmantot dažādus trikus, lai ap to (piemēram, nosakot prioritāro uzdevumu).

Man vajadzēja sniegt saiti uz šo uzdevumu veidlapām, kas atvērušas skata rekvizīti (dispform.asxp) "saistītā vienuma" jaunā logā. Tā nodrošina viena klikšķa piekļuvi meta datu saistītā vienuma. Tas ir tas, ko es domāju:

Laimi, mēs varam darīt, un tas nav ļoti grūti. Visumā, uguns līdz SPD, Naviģējiet uz direktoriju, kas mājas darbplūsmas failus un atveriet ASPX failu, kuru vēlaties modificēt. Šie ir tikai klasisko XSL transformāciju instrukcijas un ja jūs esat atmestās ar itemstyle.xsl, meklēšanu vai citas XSL scenārijus, tas būs viegli. patiesībā, Es atklāju, ka ir pārsvarā vienkāršāk, jo ģenerēts formā ir nedaudz vieglāk sekot salīdzinājumā ar galveno rezultātu web daļu (vai_ar ī murgainu CWQP).

protams, tur ir viens no galvenajiem lamatām. SPD darbplūsmas redaktors paredz pilnīgu kontroli pār šo failu. Ja to modificēt, VPD laimīgi pārrakstīs jūsu izmaiņas dot tiesības noteikt apstākļus. Es tā divas ātrās pārbaudes, lai redzētu, cik slikti tas varētu iegūt. Viņi abi priekšnoteikumu, ka esat izstrādāts spēkā VPD darbplūsmu, kas izmanto "savākt datus no lietotāja" solis.

Tests 1:

• Modificēt ASPX failā ar roku.
• Izmēģiniet to (Pārbaudiet, vai jūsu izmaiņas netika pareizi saglabāts un neko neizjauc).
• Uzsākt darbplūsmu un pievienot nesaistītu darbību (piemēram, "žurnāla vēsture").
• Saglabāt darbplūsmas.

Rezultāts: Šajā gadījumā, VPD nevar atkārtoti izveidot veidlapas.

Tests 2:

• Tāpat kā #1 izņemot tieši pārveidot "savākt datus no lietotāja" darbības.

Rezultāts: Atkārtoti tiek izveidots no jauna forma, pār-rakstīt jūsu veiktās izmaiņas.

Nobeiguma piezīmes:

• Vismaz divas VPD darbības izveidot formas līdzīgs šim: "Datu savākšanai no lietotāja" un "Piešķirt vienuma". Abas šīs darbības’ formas var manuāli mainīt.
• Man bija iespēja, lai radītu manu saiti uz dispform.aspx, jo, Šajā gadījumā, relate krājumam vienmēr ir tās ID, kas iegulti saistītā elementa URL. Man bija iespēja iegūt to un pēc tam veidot <href => pamatojoties uz to, lai nodrošinātu vienu klikšķi meta datu piekļuves līdzekli. Maz ticams, ka jūsu URL seko šai kārtulai. Var būt citi veidi, kā iegūt saistītā elementa ID, bet nav bijusi šo tiltu šķērsot, tāpēc es nezinu, ja saņem otras malas bezdibenis.
• Nebija izmeklēt, bet es nebūtu pārsteigts, ja pastāv zināma veida veidnes failu 12 stropu, kas varētu modificēt ietekmē kā VPD izveido noklusējuma veidlapas (līdzīgi mēs varētu modificēt brīdinājumu veidnes).

</beigās>

Abonēt manu blogu!