Ei-koodi ratkaisu: päivien näyttäminen, koska luettelon kohdetta on viimeksi muutettu

Yleiskatsaus: mukautetut erääntymis raportit, joissa ei ole koodia

Yksi SharePoint-sivuston usein pyydettävistä toiminnallisista osista on joko tehtävien tai luettelo kohteiden erääntymis raportti. Toisin sanoen, kuinka monta päivää/kuukautta on ollut, koska tätä luettelon kohdetta on viimeksi muokattu?

Pinnalla tämä näyttää olevan hyvin yksinkertainen pyyntö. Loppujen lopuksi olemme luoneet ja muokkaamiasi kohteita koskevia päivä määriä, mutta voimme tallentaa mukautettuja päivä määriä, kun tietyt muutokset tapahtuvat tapahtumien vastaanottimien kautta. Olemme laskeneet sarakkeita, joihin voimme sisällyttää Excelin kaltaisia kaavoja tietojen kanssa työskentelyyn. Tämä vaikuttaa melko suoraan eteenpäin-ehdotukselta. Valitse Päivämäärä kenttä, Luo laskettu sarake ja tee sitten kaava jollakin [DateField] – [today]-rivillä. Ah, ei niin nopeasti vaikka! Jos joku on yrittänyt tätä "yksinkertaista"-tehtävää, hän yrittää käyttää jotain muuta kuin [tänään] lasketussa sarakkeessa aiheuttaa ongelmia. Yritä lisätä [tänään] lasketun sarakkeen kaava-ruutuun saat virhe ilmoituksen seuraavanlaiselta:

Miksi tämä on? Se liittyy myös laskettujen sarakkeiden laskenta tapaan.

Oletetaan, että esimerkki on yksinkertainen kaava:

= Jos ( [Sarake1] <= [Sarake2], "OK", "ei OK")

Kaikki tämä kertoo, että jos Sarake1 on pienempi tai yhtä suuri kuin Sarake2, näyttö on OK, muutoin näyttö ei ole OK. Tämä on melko tyypillinen peruskaava laskettuun sarakkeeseen, ja siinä on perusolettama, joka sisältää seuraavat sarakkeet: Sarake1-ja Sarake2-arvot eivät koskaan voi muuttua ilman luettelon kohteen päivitys tapahtumaa.

Tämä on oikein, lasketut sarakkeet lasketaan uudelleen vasta, kun luetteloa päivitetään (tai luodaan), koska ne olettavat, että laskemasi tiedot sisältyvät itse kohteeseen. Tämä aiheuttaa ongelman, kun yrität käyttää jotain kohdetta, joka ei riipu kohteen kentistä, kuten kuluvan päivän päivä määrästä.

Nyt en ollut koko uksessa, jossa hän päätti, että tämä on se tapa, jolla lasketut sarakkeet toimisivat, mutta jos minun pitäisi tehdä koulutettu arvaus, Oletan, että ne toimivat tällä tavalla suoritus kyvyn takaamiseksi. Kuvittele, jos sinulla olisi luettelo useista tuhansittain kohteita, joista jokainen sisälsi lasketun sarakkeen, joka tarvitsi "Live"-päivityksen. Tämä merkitsisi sitä, että jokin mekanismi, ehkäpä ajastintyö, pitäisi käydä läpi jokainen kohde, joka sisälsi kyseisen lasketun sarakkeen joka niin usein ja päivittää sen arvon. Tämä voi olla erittäin hyvä suoritus kyky, koska suurempien käyttöönottojen ansiosta tämä työ voi olla käynnissä ja vaihtaa asioita. Se on vain minun arvaus, mutta siinä on paljon järkeä, jos ajattelee sitä.

On olemassa joitakin ehdotuksia, jotka koskevat samankaltaisia ratkaisuja, joissa on mukana huijaaminen SharePointia, jonka avulla voit hyväksyä tänään-arvon luomalla ensin tänään sarakkeen nimeltä ja lisäämällä sen sitten kaavaan ja poistamalla sen. Kaikki nämä ovat hyviä, mutta muista, mitä sanoin, kun laskettuja sarakkeita päivitetään. Tämä arvo muuttuu vain, kun kohde päivitetään, mikä tarkoittaa, että arvot ovat pian virheellisiä, etenkin jos päivä lasketaan.

Olen nähnyt muita käyttämään fiksua JavaScriptiä, jos haluat kirjoittaa arvot sivulle. Tämä toimisi myös, mutta olen melko jyrkästi asiakas ohjelman komento sarjaa vastaan, kun se voidaan välttää.

Käyttöönotto

Mitä tehdä? Lasketut sarakkeet eivät ole niin kutsuttu "haihtuvia" funktioita, kuten tänään. On mahdollista, että voimme kehittää jonkin mukautetun koodin ja huolehtia siitä meille, kuten laskettuun sarakkeeseen, ajastin työhön tai ajoitettuun prosessiin, ja päivittää kaikki tätä laskentaa tarvitsevat yksittäiset kohteet. Tämä tuo meidät takaisin edelliseen kappaleeseen mainitsemaani suoritus kykyyn, ja lisäksi se on hauras ratkaisu, joka on hyvin spesifinen kyseiseen sivustoon/luetteloon/sarakkeeseen. Näiden kahden huolen lisäksi sinun on myös etsittävä nörtti kaveri, kuten minä, joka tietää, miten koodi ja suostutella häntä kehittämään tätä ratkaisua puolestasi. Se on kuitenkin helpompaa!

Jos sinulla on oikeudet luoda kenttiä ja muokata sivuston sivuja ja sinulla on vähän tietoja XSLT-tiedostosta ja näkymiä luotaessa, voit koota yhteen XSL-mallin, joka voidaan sisällyttää luettelo näkymään, ja laskea arvon tarkasti aina, kun sivua pyydetään. Tämä skenaario poistaa huolemme suoritus kyvystä, eikä se edellytä mukautettua koodia kehittäviä ja käyttöönotettavia ratkaisuja.

Täydellinen. Miten se tehdään?

1. Luo tai valitse kenttä, joka toimii lähde kenttänä. Sen on oltava päivämäärä tyyppi.

2. Luo kenttämme, joka toimii paikka merkkinä lasketulle arvolle.

3. Lisää molemmat näistä kentistä sisältö tyyppiin ja lisää kyseinen sisältö tyyppi luetteloon.

4. Luo luettelon näkymä, joka sisältää sekä lähde-että paikka merkki-sarakkeet.

5. Lataa XSL-malli tyylit-kirjastoon.

6. Valitse "XSL-linkki"-ominaisuus luettelon näkymä-verkko-osalle käyttö liittymässä.

7. Valmis!

Tutkitaan esimerkki käyttö tapausta ja toteutetaan toteutusta. Asiakas halusi nähdä niiden pääluettelon, joka kertoo, kuinka kauan tietyn luettelon kohde oli istunut sen tilalla. Tämä lista sisälsi mukautetun sivuston sisältö tyypin, joka on johdettu kohde tyypistä ja lisätty luetteloon. Käytössä oli jo tapahtuma vastaanotin, joka vangitsee aina, kun luettelon kohteen tila-kenttä muutettiin, ja tallensi tämän päivä määrän sarakkeeseen, jonka nimi on "Date status muutettu". Kaikki tämä johdotus ei ole pakollinen, ja se voidaan tehdä missä tahansa päivämäärä kentässä (se käy juuri niin, että olemme valmiit kokeilemaan sitä). Tarvitsemasi vähimmäisvaatimus on lähde päivämäärä kenttä ja paikka merkki kenttä, jotta voit pitää lasku toimituksen (lisä tietoja seuraavassa kappaleessa), mutta ehdotan, että käytät sivustosarakkeita ja sivuston sisältö tyyppejä, jos haluat käyttää tätä ratkaisu tapaa uudelleen sivuston muissa paikoissa.

Meillä on siis lähde päivämäärä, jota voimme käyttää tämän päivän päivä määrää laskettaessa. Nyt voimme luoda mukautetun sivustosarakkeen käytettäväksi säilönä lasketulle arvolle. Tässä tapa uksessa päätin käyttää laskettua saraketta, koska sitä ei voi muuttaa uusien tai muokattavien kohteiden lomakkeissa, mutta se voidaan valita näkymään näkymissä, koska emme halua käyttäjien syöttäviä satunnaisia arvoja tähän sarakkeeseen. Se voi olla hämmentävää, miksi se ei näy näkymissä jne.

Nyt kun meillä on sivustopalstamme, voimme lisätä sen sisältö tyyppeihin, joita käytetään listallamme. Seuraavaksi meidän on luotava näkymä, joka mukautetaan myöhemmin XSLT-paketteihimme. Varmista, että luot vakio näkymän, joka sisältää lähde päivämäärä sarakkeen ja uuden lasketun sarakkeen, joka toimii paikka merkkinä lasketulle arvolle.

Meillä on nyt kaikki tarvittavat tiedot, jotka vaadimme tuke maan mukautettua erääntymis raporttia. Jäljelle jää vain luo XSL-mallimme, Lataa se sivuston Tyylikirjastoomme ja linkitä se luettelo näkymään. Käytettävä XSL-malli sisältää yleensä SharePointin luoman merkinnän, jonka avulla voit luoda näkymän sekä oman mukautetun merkinnän, jota käytetään tämän osan ohittamiseksi ja halutun arvon laskemiseen meille.

Kun saldo on erääntynyt, XSL-mallit, jotka tekevät todellisia lasku toimituksia tällä ratkaisulla, on annettu ystävällisesti "pyörteitä" MSDN-foorumeissa:
http://Social.MSDN.Microsoft.com/forums/en-US/sharepointcustomization/Thread/aeda905b-9bc6-40c4-BD22-21306c5cb0d2/

Lataa XSL-tyyli taulukko (aging.zip), joka on koottu tänne:
https://OneDrive.live.com/?Cid=c262e8e2d59a86d9&permissionsChanged = 1&ID = c262e8e2d59a86d9! 104

Kun avaat tämän tekstin suosikkitekstimuokkaimesi, näyttöön tulee paljon normaaleja SharePointin XSL-merkintöjä, jotka tekevät näkymästä vierittämisen, kun siirryt riville 357, ja näkyviin tulee merkintä, joka on ensimmäinen, joka on "DateDiff"-malli ja sen jälkeen "Laske-Julian-Day" ja "FieldRef_printTableCell_EcbAllowed. Days_x0020_At_x0020_Status". Nämä ovat kolme mallimme, jotka tekevät ja näyttävät laskelmamme meidän näkemyksissä. Jos aiot käyttää eri kenttien nimiä kuin tässä artikkelissa on määritetty aikaisemmin, sinun on suoritettava nämä mallit ja korvattava kaikki viitta ukset muihin nimiin. Muista, että tämä edellyttää, että kentän sisäinen nimi ei ole näyttö nimi.

Kun olet varmistanut, että malli on valmis, Siirry omaan Tyylikirjastoosi ja lataa se XSL-tyylisivut-kansioon ja kopioi sitten linkki tiedostoon. Näin voimme tehdä siihen helposti muutoksia myöhemmin tai lisätä ne sivuston eri osiin.

Siirry seuraavaksi luetteloon ja valitse näkymä, jonka loit aikaisemmin tässä artikkelissa. Valitse sivuston Toiminnot-valikosta Muokkaa sivua.

Etsi sivulta luettelon näkymä-verkko-osa ja avaa verkko-osa-valikko napsauttamalla pientä alaspäin osoittavaa nuolta oikeassa yläkulmassa. Valitse tästä valikosta Muokkaa verkko-osaa.

Tämä avaa selain ikkunan oikeassa laidassa olevan verkko-osan valikon.

Napsauta Muut-osion +-kohtaa ja Etsi XSL-linkki-ominaisuus.

Liitä linkki XSL-tiedostoon tyyli kirjastossa, jonka kopioit aikaisemmin (tämä voi olla suhteellinen tai suora linkki).

Tallenna muutokset valitsemalla OK ja napsauta sitten sivun yläreunassa olevan sivun valinta nauhan Lopeta muokkaaminen-painiketta.

Jos kaikki on määritetty oikein, sinun pitäisi nyt nähdä numerot päivät tila-sarakkeessa.

Ja lopuksi, tässä on se, miltä se näyttää eri päivä määrien testi tiedoilla:

Yhteenveto:

Siinä on: kauniisti muotoiltua, vankkaa ja parempaa tapaa luoda erääntymis raportti SharePointissa., jossa on yksinkertainen No-Code-toteutus. Tämä on melko paljon mahdollisia sovelluksia syrjään yksi käyttö tapa uksessa olemme tutkineet täällä. Toinen yleinen skenaario tämäntyyppisen raportin liittämisessä on tehtävä luetteloon, jotta näet, kuinka kauan se on ollut, koska tehtävä on luotu yhdellä silmäyksellä.

Nauti sovelluksesta!

--Justin

Justin Joyce, LANtek

Kommentit

Puuttuvat
vaiheet 10/8/2012 3:51 AM
OK seurasin vaiheita, mutta jotain puuttuu-miten XSL tietää, mitä päivä määrää käytetään, tai mikä kenttä lisää päiviä sen jälkeen? Vihaan sitä, kun vaiheet ovat jääneet.

Ei-koodi, sovittu!
8/30/2012 12:12 PM
Olen samaa mieltä-en usko, että tämä todella lasketaan "ei koodia".
Kiinnostavaa on se, että minulla on työlaskettu sarake, jossa on jo nyt käytössä... Etkö ole varma, miten tai miksi en saa sitä uudelleen, mutta se on edelleen olemassa ja toimii.

Lasketun sarakkeen päivät-tila kaava?
5/2/2012 7:39 AM
Justin-mikä on kaava, jota käytit päivät-tila-kohdassa lasketun sivuston sarakkeessa (paikka merkki-sarakkeessa)? Oliko se "= tänään"?

SharePoint 2007
12/2/2011 11:29 AM
Tällä hetkellä en ole yrittänyt käyttää tätä ratkaisua SharePoint 2007, mutta odotan sitä. Verkko-osassa ei valitettavasti ole XslLink-ominaisuutta käyttö liittymän kautta.

Erinomainen viesti
11/30/2011 9:53 AM
Hei,
Great post.
Käytän SharePoint 2007-käyttöä.
Minulla ei ole muita osia, kuten edellä on mainittu.
Onko sinulla SP2007-kokoonpanon vaiheita?
Kiitos.

Re: ei-koodi ratkaisu: päivien näyttäminen, koska SharePoint-luettelon kohdetta on viimeksi muutettu
10/11/2011 8:24 AM
Hei Chris.
hyvä löytää!
aion vilkaista, mitä olet lähettänyt toivottavasti myöhemmin tänään, ja Katso, Voinko tehdä tästä ratkaisusta hieman vankempaa.
Olen iloinen siitä, että pidit viestistä, ja olen erittäin iloinen, että kykenit löytämään ratkaisun eurooppalaiseen päivämäärä muotoon. :)
-Justin

Ratkaisu eurooppalaisiin päivämäärä muotoihin
10/11/2011 6:45 AM
Hei taas Justin,
TIEDOKSESI, löysin ratkaisun aiemmin mainitsemaani ongelmaan tällä sivulla;
https://sharepointbydummies.WordPress.com/2011/07/13/possible-Work-around-to-date-format-Issue-SharePoint-2010/

Euroopan päivämäärä muodot
10/7/2011 3:59 AM
Hei Justin,
Tämä on todella hyvä ratkaisu Kiitos, ja juuri sellainen asia, jonka olen viettänyt viimeiset kaksi päivää etsimässä! Minulla on kuitenkin hieman ongelmia sen kanssa, ja toivoin, että voisitte auttaa minua.
Olen muuttanut koodiasi hieman lasketen päivien määrän, kunnes jotain tapahtuu, eikä sen jälkeen, vaihtamalla muuttujia DateDiff-funktion viimeisellä rivillä.

<XSL:Value-of Select = "$JulianToday-$JulianStartDate" ></XSL:Value-of>

Olen kuitenkin ainoa mahdollisuus saada se caclolate ero oikein puolet ajasta. Esimerkiksi tämä päivä määrä (Format DD/kk/vvvv);

30/12/2011

Se laskee oikein, mutta tämä päivä määrä (sama muoto)

12/10/2011

Se laskee kuin 12-Oct-2011 sen sijaan, että se olisi 10-Dec-2011.
Yritin vain vaihtaa päivä-ja kuukausi-arvojen sijaintia "JulianStartDate"-muuttujassa, kuten tässä.

<XSL: with-PARAM Name = "kuukausi" Select = "alimerkkijono (ddwrt: FormatDateTime (merkki jono ($StartDate), 1033, ' Yyvvkkpp '), 7, 2)"/>
<XSL: with-PARAM Name = "päivä" Select = "alimerkkijono (ddwrt: FormatDateTime (merkki jono ($StartDate), 1033, ' Yyvvkkpp '), 5, 2)"/>

Tämä korjasi ongelman toisella päivä määrällä, mutta sen jälkeen se oli virheellinen ensimmäiselle päivä määrälle.
Olen myös yrittänyt muuttaa FormatDateTime-puhelut käyttämään eurooppalaisia LCID-kutsuja ja erilaisia muutoksia viimeiseen FormatDateTime-parametriin (esimerkiksi Ddmvvvv, Kkddyyyy), jossa on tarvittavat muutokset alimerkkijonon sijainti parametreihin ilman menestystä.
Arvostan suuresti neuvoja, joita voit tarjota.
Kiitos,
Chris

No-Code
9/21/2011 4:27 AM
En usko, että XSL on "ei-koodi"-ratkaisu, sillä XSL-kielen ymmärtäminen ei ole kaikille, mutta se ei edellytä ohjelmointia. Sen lisäksi, että: mukava ratkaisu, kiitos!