Koodia vailla oleva ratkaisu: Luettelokohteen edellisen vaihdon jälkeisien päivien näyttäminen

Yleiskatsaus: Mukautetut erääntymisraportit ilman koodia

Yksi SharePoint-sivuston usein pyydetyistä toiminnallisista osista on joko tehtävien tai luettelokohteiden erääntymisraportti. Toisin sanoen kuinka monta päivää/kuukausi on kulunut siitä, kun tätä luettelokohdetta on viimeksi muokattu?

Pinnalla tämä näyttää olevan hyvin yksinkertainen pyyntö. Loppujen lopuksi meillä on päivämääriä luotaville ja muokattaville kohteille, ja voimme tallentaa mukautettuja päivämääriä, kun tietyt kohteiden muutokset tapahtuvat tapahtumavastaanottimien kautta. Olemme laskeneet sarakkeita, joissa voimme sisällyttää Excelin kaltaisia kaavoja tietojen käsittelemistä varten. Tämä vaikuttaa melko suoralta ehdotukselta. Valitsemme päivämääräkentän, luomme lasketun sarakkeen ja teemme sitten kaavan, joka on [DateField] – [Tänään]. Ei kuitenkaan niin nopeasti! Kuten kaikki tämän yksinkertaisen tehtävän yritykset tietävät, esimerkiksi [Tänään] -toiminnon käyttäminen lasketussa sarakkeessa aiheuttaa ongelmia. Yritä lisätä [Tänään] lasketun sarakkeen kaavaruutuun antaa seuraavanlaisen virhesanoman:

Miksi tämä on? Se liittyy laskettujen sarakkeiden laskentatapaan.

Otetaan esimerkki yksinkertaisesta kaavasta:

= JOS( [Sarake1]<=[Sarake2], "OK", "Ei OK")

Kaikki tämä tarkoittaa, että jos Sarake1 on pienempi tai yhtä suuri kuin Sarake2, näytä OK, muussa tapauksessa näytä Ei OK. Tämä on melko tyypillinen lasketun sarakkeen peruskaava, ja se tekee perusoletuksen luettelokohteesta, joka sisältää nämä sarakkeet: Sarake1- ja Sarake2-arvot eivät voi koskaan muuttua ilman Luettelokohteen Päivitä-tapahtumaa.

Lasketut sarakkeet lasketaan uudelleen vain, kun luettelo päivitetään (tai luodaan), koska ne olettavat, että laskettavat tiedot sisältyvät itse kohteeseen. Tämä aiheuttaa ongelman, kun yrität käyttää jotakin, joka muuttuu kohteen kentistä riippumatta, kuten kuluvan päivän päivämäärää.

Nyt en ollut kokouksessa, jossa he päättivät, että lasketut sarakkeet toimivat näin, mutta jos minun pitäisi tehdä koulutettu arvaus, oletan, että ne toimivat näin suorituskyvyn kannalta. Kuvittele, jos sinulla olisi luettelo useista tuhansista kohteista, joista jokainen sisälsi lasketun sarakkeen, joka tarvitsi reaaliaikaisen päivityksen. Tämä tarkoittaisi sitä, että jokin mekanismi, ehkä ajastintyö, joutuisi iteroimaan jokaisen sellaisen kohteen läpi, joka sisälsi lasketun sarakkeen niin usein, ja päivittämään sen arvon. Tämä voi olla erittäin verottavaa suorituskyvyn kannalta, koska suuremmissa käyttöönotoissa tämä työ saattaa olla jatkuvasti käynnissä ja muuttaa asioita. Se on vain arvaukseni, mutta siinä on järkeä, jos ajattelet sitä.

On olemassa joitakin ehdotuksia samankaltaisista ratkaisuista, jotka sisältävät SharePointin huijaamisen hyväksymään Tänään-arvon luomalla ensin Tänään-nimisen sarakkeen, lisäämällä sen sitten kaavaan ja poistamalla sen. Nämä ovat kaikki hyviä, mutta muista, mitä sanoin, kun laskettuja sarakkeita päivitetään. Tämä arvo muuttuu vain, kun kohde päivitetään, mikä tarkoittaa, että arvosi ovat pian virheellisiä erityisesti päivän laskennan yhteydessä.

Olen nähnyt muiden kirjoittavan arvot sivulle älykkään JavaScriptin avulla. Tämä toimisi myös, mutta vastustan melko ehdottomasti asiakaskomentosarjaa, kun se voidaan välttää.

Toteutus:

Mitä tehdä? Lasketut sarakkeet eivät tule kysymykseen niin kutsutuille "haihtuville" funktioille, kuten Tänään. On mahdollista, että voimme kehittää joitakin mukautettuja koodeja tämän hoitamiseksi, kuten lasketun sarakkeen, ajastintyön tai ajoitetun prosessin, jotta voimme päivittää jokaisen kohteen, joka tarvitsee tämän laskutoimituksen. Tästä pääsemmekin takaisin edellisessä kappaleessa mainitsemaani suorituskykyongelmaan, ja lisäksi se on hauras ratkaisu, joka olisi erittäin erityinen kyseiselle sivustolle/ luettelolle tai sarakkeelle. Näiden kahden huolenaiheen lisäksi sinun pitäisi myös etsiä nörtti kaveri, kuten minä, joka osaa koodata ja suostutella hänet kehittämään tämän ratkaisun puolestasi. Mutta on helpompikin tapa!

Jos sinulla on oikeus luoda kenttiä ja muokata sivuston sivuja ja sinulla on hieman tietoa XSLT:stä ja näkymien luomisesta, voit koota XSL-mallin, joka voidaan sisällyttää luettelonäkymään ja joka laskee arvosi aina, kun sivua pyydetään. Tämä skenaario poistaa huolemme suorituskyvystä eikä edellytä mukautetun koodin kehittämistä ja käyttöönottoa ratkaisun kautta.

Mahtavaa. Miten se tehdään?

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

2. Luo kenttä, joka toimii laskettavan arvon paikkamerkkinä.

3. Lisää molemmat kentät sisältötyyppiin ja lisää kyseinen sisältötyyppi luetteloon.

4. Luo luettelonäkymä, joka sisältää sekä lähde- että paikkamerkkisarakkeet.

5. Lataa XSL-malli Tyylikirjastoon.

6. Määritä Luettelonäkymä-verkko-osan XSL-linkki -ominaisuus käyttöliittymän kautta.

7. Valmis!

Tutustutaan esimerkkikäyttötapaukseen ja käydään läpi käyttöönotto. Asiakkaamme halusi pääluettelon näkymän, joka kertoisi, kuinka kauan tietty luettelokohde oli istunut sen tilalla. Tämä luettelo sisälsi mukautetun sivuston sisältötyypin, joka on johdettu kohdetyypistä ja lisätty luetteloon. Paikalla oli jo tapahtumavastaanotin, joka tallentaa joka kerta, kun luettelokohteen tilakenttää muutettiin ja kyseinen päivämäärä tallennettiin sarakkeeseen nimeltä "Päivämäärän tila muutettu". Kaikki tämä johdotus ei ole pakollista, ja se voidaan tehdä millä tahansa päivämääräkentällä (tapahtuu niin, että tämä on meidän käyttöönottomme, mutta voit vapaasti kokeilla). Vähimmäismäärä, jonka tarvitset, on lähdepäivämääräkenttä ja paikkamerkkikenttä, jotta voit pitää luetteloon lisätyn laskutoimituksen (lisätietoja tästä seuraavassa kappaleessa), mutta ehdotan, että käytät sivustosarakkeita ja sivuston sisältötyyppejä siltä varalta, että haluat käyttää tätä ratkaisua uudelleen sivuston muissa paikoissa.

Meillä on siis lähdepäivämäärä, jota voimme käyttää laskutoimituksessamme kuluvan päivän päivämäärän mukaan. Nyt voimme luoda mukautetun sivustosarakkeen, jota käytetään lasketun arvon säilönä. Tässä tapauksessa päätin käyttää laskettua saraketta, koska sitä ei voi muuttaa uusissa tai muokattavissa kohdelomakkeissa, mutta se voidaan valita näytettäväksi näkymissä, koska emme halua käyttäjien syöttävän satunnaisia arvoja tähän sarakkeeseen. Voi olla hämmentävää, miksi sitä ei näytetä näkymissä jne.

Nyt kun meillä on sivustosarake, voimme lisätä sen sisältötyyppeihimme, joita käytetään luettelossamme. Seuraavaksi meidän on luotava näkymä, joka mukautetaan myöhemmin XSLT:n avulla. Varmista, että luot vakionäkymän, joka sisältää lähdepäivämääräsarakkeen ja uuden lasketun sarakkeen, joka toimii lasketun arvon paikkamerkkinä.

Meillä on nyt kaikki, mitä tarvitsemme mukautetun erääntymisraportin tukemiseksi. Jäljellä on vain XSL-mallin luominen, sen lataaminen sivuston tyylikirjastoon ja sen linkittäminen luettelonäkymään. XSL-malli, jota käytämme, sisältää joitain normaaleja SharePointin luomia merkintöjä näkymän luomista varten sekä omia mukautettuja merkintöjä, joita käytetään ohittamaan tietyt osat tästä ja laskemaan meille haluamamme arvon.

Kun luotto erääntyy, XSL-mallit tähän ratkaisuun käyttämieni todellisten laskutoimitusten tekemiseen annettiin ystävällisesti MSDN-keskustelupalstoilla "swirch":
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Lataa XSL-tyylitaulukko (aging.zip), jonka olen koonnut täällä:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&käyttöoikeudetChanged=1&id=C262E8E2D59A86D9!104

Kun tämä avataan suosikkitekstieditorissasi, näet runsaasti tavallisia SharePoint XSL -merkintöjä näkymien hahmontamista varten. Jos jatkat vierittämistä riville 357 asti, näet merkinnäseen lisäämieni mukautettujen mallien alun, joista ensimmäinen on DateDiff-malli ja sen jälkeen "calculate-julian-day" ja "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Nämä ovat kolme malliamme, jotka tekevät ja näyttävät laskelmamme näkymissämme. Jos aiot käyttää eri kenttien nimiä kuin tässä artikkelissa aiemmin on määritetty, sinun on käytävä nämä mallit läpi ja korvattava viittaukset muihin nimiin. Muista, että tässä tapauksessa haluat käyttää kentän SISÄISTÄ nimeä näyttönimen sijaan.

Kun olet tyytyväinen siihen, että malli on valmis, siirry tyylikirjastoon ja lataa se XSL-tyylisivut-kansioon ja kopioi sitten tiedostolinkki. Näin voimme helposti tehdä siihen muutoksia myöhemmin tai lisätä sen sivuston eri osiin haluamallamme tavalla.

Siirry seuraavaksi luetteloon ja valitse aiemmin tässä artikkelissa luomasi näkymä. Valitse Sivuston toiminnot -valikosta Muokkaa sivua.

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

Tämä avaa verkko-osan valikon selainikkunan oikeassa reunassa.

Napsauta +-painiketta Muut-osassa ja etsi XSL-linkki-ominaisuus.

Liitä aiemmin kopioimasi tyylikirjaston XSL-tiedoston linkki (tämä voi olla suhteellinen tai suora linkki).

Tallenna muutokset valitsemalla OK ja napsauta sitten Sivun-valintanauhan Lopeta muokkaaminen -painiketta sivun yläreunassa.

Jos kaikki on määritetty oikein, numeroiden pitäisi nyt näkyä Tilapäivät-sarakkeessa.

Ja lopuksi, tältä se näyttäisi joidenkin eri päivämäärien testitietojen kanssa:

Yhteenveto:

Siinä se on: hienosti muotoiltu, vankka ja paremmin suoriutuva tapa luoda erääntymisraportti SharePointissa, joka sisältää yksinkertaisen koodittoman toteutuksen. Tässä on monia mahdollisia sovelluksia lukuun ottamatta yhtä käyttötapausta, jota tutkimme täällä. Toinen yleinen skenaario tämäntyyppiselle raportille on sen liittäminen tehtäväluetteloon, jotta näet, kuinka kauan tehtävän luomisesta on kulunut yhdellä silmäyksellä.

Toivomme, että pidät näistä uusista ominaisuuksista.

--Justin

Justin Joyce, LANtek

Kommentit

Vaiheet puuttuvat
8.10.2012 3:51
ok Noudatin vaiheita, mutta jotain on puututtava – miten XSL tietää, mitä päivämäärää käytetään tai mihin kenttään päivät lisätään? vihaa sitä, kun vaiheet ohitetaan.

Ei koodia, sovittu!
30.8.2012 klo 12.12
Olen samaa mieltä - en usko, että tätä todella lasketaan "ei koodia".
Mielenkiintoista on, että SharePointin ruuvaamisen kautta minulla on toimiva laskettu sarake tänään... en tiedä, miten tai miksi, koska en saa sitä tekemään sitä uudelleen, mutta se on edelleen siellä ja toimii.

Kaava "Päivät tilassa" -lasketun sarakkeen kaava?
2.5.2012 klo 7.39
Justin – Mikä on kaava, jota käytit "Days At Status" -lasketussa sivustosarakkeessa (paikkamerkkisarake)? Oliko se "=tänään"?

SharePoint 2007
2.12.2011 11:29
En ole tällä hetkellä yrittänyt ottaa tätä ratkaisua käyttöön SharePoint 2007:ssä, mutta tarkastelen sitä. Valitettavasti verkko-osassa ei ole XslLink-ominaisuutta käyttöliittymän kautta.

Upea viesti
30.11.2011 9:53
Hei
Upea viesti.
Käytän SharePoint 2007:ää.
Minulla ei ole misc-osiota edellä kuvatulla tavalla.
Onko sinulla SP2007-määrityksen vaiheet?
Kiitos.

Re: Ei koodia -ratkaisu: Näytetään päivät, jolloin SharePoint-luettelokohdetta on viimeksi muutettu
11.10.2011 8:24
Hei Chris.
erinomainen löytö!
Katson, mitä julkaisit toivottavasti myöhemmin tänään, ja katson, voinko tehdä tästä ratkaisusta hieman vankemman.
Olen iloinen, että pidit viestistä, ja olen erittäin iloinen, että löysit ratkaisun eurooppalaiseen päivämäärämuotoon.
:) -Justin

Ratkaisu eurooppalaisiin päivämäärämuotoihin
11.10.2011 6:45
Hei taas, Justin.
FYI, löysin ratkaisun ongelmaan, jonka mainitsin aiemmin tällä sivulla;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Eurooppalaiset päivämäärämuodot
7.10.2011 3:59
Hei Justin,
Tämä on todella hyvä ratkaisu kiitos, ja juuri sellaista olen viettänyt viimeiset kaksi päivää etsien! Minulla on kuitenkin pieni ongelma sen kanssa ja toivoin, että voisit auttaa minua.
Olen muuttanut koodiasi hieman laskeakseni päivien määrän, kunnes jotain tapahtuu, en sen jälkeen, vaihtamalla muuttujat DateDiff-funktion viimeisellä rivillä;

<xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of>

Voin kuitenkin saada sen vain, jotta ero saadaan aikaan oikein puolet ajasta. Esimerkiksi tämän päivämäärän kanssa (muoto kk/kk/vvvv);

12.3.2011

Se laskee oikein, mutta tällä päivämäärällä (samassa muodossa)

10.12.2011

Se laskee ikään kuin 10.12.2011 eikä 12.10.2011.
Yritin yksinkertaisesti vaihtaa päivä- ja kuukausiarvojen sijainnit "JulianStartDate" -muuttujassa näin;

<xsl:with-param name="Month" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),7,2)"/>
<xsl:with-param name="Day" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),5,2)"/>

Ja tämä korjasi ongelman toisella päivämäärällä, mutta se oli sitten virheellinen ensimmäisellä päivämäärällä!
Olen myös yrittänyt muuttaa FormatDateTime-kutsuja käyttämään eurooppalaisia LCID-tunnuksia ja erilaisia muutoksia FormatDateTimen viimeiseen parametriin (esimerkiksi ddMMyyyyy, MMddyyyy) asianmukaisilla mukautuksilla alimerkkijonon sijaintiparametreihin tuloksetta.
Arvostaisin suuresti neuvoja, joita voit tarjota.
Kiitos
Chris

Ei koodia
21.9.2011 4:27
En usko, että XSL voidaan luokitella koodittomaksi ratkaisuksi, koska XSL-kielen ymmärtäminen ei ole kaikille - mutta siihen ei liity ohjelmointia. Sen lisäksi: Mukava ratkaisu, kiitos!