Kodsuz çözüm: Liste öğesinin son değiştirilmesinden bu yana geçen günleri görüntüleme

Genel Bakış: Kodsuz Özel Eskime Raporları

SharePoint sitesinin sık istenen işlevsel parçalarından biri, görevler veya liste öğeleri için eskiyen bir rapordur. Başka bir deyişle, bu liste öğesinin son değiştirilmesinden bu yana kaç gün/ay geçti?

Yüzeyde bu çok basit bir istek gibi görünüyor. Sonuçta, oluşturulan ve değiştirilen öğelere ilişkin tarihlerimiz var, öğelerde belirli değişiklikler olay alıcıları aracılığıyla gerçekleştiğinde özel tarihleri depolama olanağına sahibiz. Bilgilerimizle çalışmak için Excel benzeri formüller ekleyebileceğimiz sütunları hesapladık. Bu oldukça ileriye dönük bir teklif gibi görünüyor. Bir tarih alanı seçer, hesaplanmış sütun oluşturur ve sonra [DateField] – [Today] satırları boyunca bir formül yaparız. Ama o kadar hızlı değil! Bu "basit" görevi deneyen herkesin bildiği gibi, hesaplanmış bir sütunda [Bugün] gibi bir şeyi kullanmaya çalışmak sorunlara neden olur. Hesaplanmış sütununuzun formül kutusuna [Bugün] eklemeyi deneyin, aşağıdakine benzer bir hata iletisi verir:

Bu neden? Hesaplanmış sütunların hesaplanma şekliyle ilgili.

Örnek olarak basit bir formül ele alalım:

= EĞER( [Sütun1]<=[Sütun2], "Tamam", "Tamam Değil")

Tüm bunlar, Sütun1 Sütun2'den küçük veya buna eşitse Tamam'ı, aksi takdirde Tamam değil'i görüntülediğini gösterir. Bu, hesaplanan sütun için oldukça tipik bir temel formüldür ve bu sütunları içeren liste öğesi hakkında temel bir varsayımda bulunur: Sütun1 ve Sütun2 değerleri, liste öğesinde Update olayı olmadan hiçbir zaman değiştirilemez.

Doğru, hesaplanmış sütunlar yalnızca liste güncelleştirildiğinde (veya oluşturulduğunda) yeniden hesaplanır çünkü hesapladığınız bilgilerin öğenin kendisinde bulunduğunu varsayarlar. Bu, bugünün tarihi gibi öğenin alanlarından bağımsız olarak değişen bir öğeyi kullanmaya çalıştığınızda bir sorun oluşturur.

Şimdi hesaplanmış sütunların bu şekilde çalıştığına karar verdikleri toplantıda değildim, ancak eğitimli bir tahminde bulunmam gerekirse, performans için bu şekilde çalıştıklarını varsayıyorum. Her biri "canlı" güncelleştirme gerektiren bir hesaplanmış sütun içeren birkaç bin öğeden oluşan bir listenize sahip olduğunuzu düşünün. Bu, bir zamanlayıcı işi gibi bir mekanizmanın bu hesaplanmış sütunu içeren her öğeyi sık sık yinelemesi ve değerini güncelleştirmesi gerekeceği anlamına gelir. Bu, performans açısından son derece zorlayıcı olabilir çünkü daha büyük dağıtımlarda bu iş sürekli çalışıyor ve işleri değiştiriyor olabilir. Bu sadece benim tahminim, ama düşünürsen biraz mantıklı geliyor.

SharePoint'i bugün değerini kabul etmek için kandırmayı, önce Bugün adlı bir sütun oluşturup sonra formülünüze eklemeyi ve sonra silmeyi içeren bazı öneriler vardır. Bunların hepsi iyi ve iyi, ancak hesaplanmış sütunlar güncelleştirildiğinde ne söylediğimi unutmayın. Bu değer yalnızca öğe güncelleştirildiğinde değişir; bu da özellikle de gün hesaplaması söz konusu olduğunda değerlerinizin yakında yanlış olacağı anlamına gelir.

Sayfaya değerleri yazmak için akıllı JavaScript kullanan başkalarını da gördüm. Bu da işe yarayacaktı, ancak kaçınılabilir olduğunda istemci betiğine karşı kategorik olarak oldukça fazlayım.

Uygulama:

Peki ne yapmalı? Bugün gibi "geçici" işlevler olarak adlandırılan hesaplanmış sütunlar söz konusu değildir. Hesaplanmış Sütun, zamanlayıcı işi veya zamanlanmış işlem gibi bu hesaplamanın yapılması gereken her öğeyi güncelleştirmek üzere bizim için bunu halledecek bazı özel kodlar geliştirmemiz mümkündür. Bu da son paragrafta belirttiğim performans sorununa geri dönmemizi sağlar ve buna ek olarak söz konusu siteye/listeye/sütuna son derece özel olabilecek bir kırılgan çözümdür. Bu iki endişenin yanı sıra, onu sizin için bu çözümü geliştirmesi için nasıl kodlayıp ikna edeceğini bilen benim gibi bir adam da bulmanız gerekir. Ama daha kolay bir yolu var!

Sitenizde alan oluşturma ve sayfaları düzenleme haklarına sahipseniz ve XSLT ve görünüm oluşturma hakkında biraz bilgi sahibiyseniz, liste görünümüne dahil edilebilen ve sayfa istenildiğinde değerinizi sadık bir şekilde hesaplayacak bir XSL şablonu oluşturabilirsiniz. Bu senaryo performansla ilgili endişemizi ortadan kaldırır ve özel kodun bir çözüm aracılığıyla geliştirilip dağıtılması gerekmez.

Mükemmel. Peki nasıl yapacağız?

1. Kaynağımız gibi davranacak alanı oluşturun veya seçin. Bu bir tarih türü olmalıdır.

2. Hesaplanacak değer için yer tutucu görevi yapacak alanımızı oluşturun.

3. Bu alanların ikisini de bir içerik türüne ekleyin ve bu içerik türünü bir listeye ekleyin.

4. Bu listenin hem kaynak hem de yer tutucu sütunlarını içeren bir görünümünü oluşturun.

5. XSL şablonunu Stiller Kitaplığı'na yükleyin.

6. Kullanıcı arabirimi aracılığıyla Liste Görünümü Web Bölümü için "XSL Bağlantısı" özelliğini ayarlayın.

7. Başarılı!

Şimdi örnek bir kullanım örneğini keşfedelim ve uygulamayı gözden geçirelim. Müşterimiz, belirli bir liste öğesinin durumunda ne kadar süre kaldığını belirten ana listesinin bir görünümünü istedi. Bu liste, Öğe türünden türetilen ve listeye eklenen özel bir site içerik türü içeriyordu. Liste öğesindeki durum alanı değiştirildiğinde ve bu tarihi "Tarih Durumu Değiştirildi" adlı bir sütuna kaydedildiğinde yakalayan bir olay alıcısı zaten vardı. Tüm bu kablolama gerekli değildir ve ANY tarih alanı ile yapılabilir (böyle olur, bu bizim uygulamamızdır ama denemeden çekinmeyin). İhtiyacınız olan en düşük değer kaynak tarih alanı ve yer tutucu alanınızdır (sonraki paragrafta bu konuda daha fazla bilgi) listenize eklenir, ancak bu çözümü sitenizdeki diğer yerlerde yeniden kullanmak istemeniz durumunda site sütunlarını ve site içerik türlerini kullanmanızı öneririm.

Bu nedenle, bugünkü tarihe göre hesaplamamızda kullanabileceğimiz kaynak tarihimiz vardır. Artık hesaplanmış değerimiz için kapsayıcı olarak kullanılacak özel bir site sütunu oluşturabiliriz. Bu durumda hesaplanmış bir sütun kullanmayı seçtim çünkü yeni veya düzenleme öğesi formlarında değiştirilemez, ancak kullanıcıların bu sütuna rastgele değerler girmesini istemediğimiz için görünümlerde görüntülenmek üzere seçilebilir. Görünümlerde neden görüntülenmediği vb. kafa karıştırıcı olabilir.

Artık site sütunumuza sahip olduğumuza göre, bunu listemizde kullanılacak içerik türlerimize ekleyebiliriz. Daha sonra XSLT ile özelleştirilecek görünümümüzü oluşturmamız gerekiyor. Kaynak tarih sütununuzu ve hesaplanmış değer için yer tutucu görevi üstlenecek yeni hesaplanmış sütununuzu içeren standart bir görünüm oluşturduğunuzdan emin olun.

Artık özel yaşlandırma raporumuzu desteklemek için ihtiyacımız olan her şey hazır. Geriye kalan tek şey XSL şablonumuzu oluşturmak, sitenin Stil Kitaplığı'na yüklemek ve liste görünümümüze bağlamaktır. Kullanacağımız XSL şablonu, görünümü oluşturmak için normal SharePoint tarafından oluşturulan bazı işaretlemeleri ve bunun belirli bölümlerini geçersiz kılmak ve bizim için istenen değeri hesaplamak için kullanılan kendi özel işaretlememizi içerecektir.

Kredinin ödendiği yerde kredi verildiğinde, bu çözüm için kullandığım gerçek hesaplamaları yapmak için kullanılan XSL şablonları MSDN forumlarında "swirch" tarafından memnuniyetle sağlanmıştır:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Burada bulunan XSL stil sayfasını (aging.zip) indirin:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

Bunu sık kullanılan metin düzenleyicinizde açtığınızda, görünümleri işlemek için çok sayıda normal SharePoint XSL işaretlemesi görürsünüz. 357. satıra kadar kaydırmaya devam ederseniz, işaretlemeye eklediğim özel şablonların başlangıcını, ilki "DateDiff" şablonu ve ardından "calculate-julian-day" ve "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status" görürsünüz. Bunlar, hesaplamalarımızı görünümlerimizde yapacak ve görüntüleyecek üç şablonumuz. Bu makalenin önceki bölümlerinde belirtilenden farklı alan adları kullanacaksanız, bu şablonları gözden geçirmeniz ve diğer adlara yapılan başvuruları değiştirmeniz gerekir. Bunun için görünen adı değil alanın İç adını kullanmak istediğinizi unutmayın.

Şablonun kullanıma hazır olduğundan emin olduktan sonra Stil Kitaplığınıza gidin ve "XSL Stil Sayfaları" klasörüne yükleyin ve ardından dosyanın bağlantısını kopyalayın. Bu, daha sonra kolayca değişiklik yapmamıza veya istediğimiz gibi sitenin farklı bölümlerine eklememize olanak sağlar.

Ardından, listenize gidin ve bu makalenin önceki bölümlerinde oluşturduğunuz görünümü seçin. "Site Eylemleri" menüsünden "Sayfayı Düzenle"ye tıklayın.

Sayfada Liste Görünümü Web Bölümünü bulun ve sağ üst köşedeki aşağı dönük küçük oka tıklayarak Web Bölümü menüsünü açın. Bu menüden "Web Bölümünü Düzenle"yi seçin.

Bu işlem, tarayıcı pencerenizin sağ tarafındaki Web Bölümü menüsünü açar.

"Çeşitli" bölümü için + işaretine tıklayın ve "XSL Bağlantısı" özelliğini bulun.

Daha önce kopyaladığınız Stil Kitaplığınızdaki XSL dosyanızın bağlantısını yapıştırın (bu göreli veya mutlak bir bağlantı olabilir).

Değişikliklerinizi kaydetmek için "Tamam"a tıklayın ve ardından sayfanın üst kısmındaki "Sayfa" şeridindeki "Düzenlemeyi Durdur" düğmesine tıklayın.

Her şey doğru yapılandırıldıysa artık "Days At Status" sütununuzda sayıları görmeniz gerekir.

Son olarak, çeşitli tarihlerdeki bazı test verileriyle şöyle görünür:

Özet:

İşte burada: SharePoint'te basit bir kodsuz uygulamayla birlikte eskime raporu oluşturmanın güzel biçimlendirilmiş, sağlam ve daha iyi performans gösteren bir yolu. Burada incelediğimiz tek kullanım örneği dışında oldukça az olası uygulama vardır. Bu tür bir rapor için yaygın olarak kullanılan bir diğer senaryo da görev listesine eklemektir. Böylece, bir görevin oluşturulmasından bu yana ne kadar zaman geçtiğini bir bakışta görebilirsiniz.

Keyfini çıkarın!

--Justin

Justin Joyce, LANtek

Açıklamalar

Adımlar eksik
08.10.2012 03:51
Tamam adımları izledim, ancak eksik bir şey olmalı- XSL hangi tarihin kullanılacağını veya o tarihten bu yana hangi alanın ekleneceğini nasıl bilecek? Adımlar atlandığında nefret ediyorum.

No-Code, kabul!
30.08.2012 12:12
Kabul ediyorum, bunun gerçekten "kod yok" olarak saydığını sanmıyorum.
İlginçtir ki, SharePoint'i biraz batırarak Bugün kullanan çalışan bir hesaplanmış sütuna sahibim... nasıl veya neden emin değilim çünkü bir daha bunu yapmak için alamıyorum, ama hala orada ve çalışıyor.

"Days at Status" Hesaplanan Sütunu için formül?
02.05.2012 07:39
Justin - "Days At Status" hesaplanmış site sütununuz (yer tutucu sütun) için kullandığınız formül nedir? "=Bugün" mü?

SharePoint 2007
2/12/2011 11:29
Şu anda bu çözümü SharePoint 2007'ye uygulama girişiminde bulunmadım, ancak bu çözümün içindeyim. Ne yazık ki kullanıcı arabirimi aracılığıyla web bölümünde ortaya herhangi bir XslLink özelliği yoktur.

Harika Gönderi
30.11.2011 09:53
Merhaba
Harika Gönderi.
SharePoint 2007 kullanıyorum.
Yukarıda belirtildiği gibi bir Misc bölümüm yok.
SP2007 yapılandırması için adımlarınız var mı?
Teşekkür ederim.

Yeniden: Kodsuz çözüm: SharePoint liste öğesinin son değiştirilmesinden
bu yana geçen günleri görüntüleme 11.10.2011 08:24
Merhaba Chris.
harika bul!
Bugün umarım daha sonra neler gönderdiğinize bir göz atacağım ve bu çözümü biraz daha sağlam hale getirebilecek miyim bakacağım.
Gönderiyi beğendiğinize sevindim ve Avrupa tarih biçimine bir çözüm bulabildiğiniz için çok mutluyum.
:) -Justin

Avrupa Tarih Biçimleri
için Çözüm 11.10.2011 06:45
Tekrar merhaba Justin,
Bilginiz olsun, bu sayfada daha önce belirttiğim sorun için bir çözüm buldum;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Avrupa Tarih Biçimleri
7/10/2011 03:59
Merhaba Justin,
Bu gerçekten iyi bir çözüm teşekkürler ve sadece son iki gün boyunca aradığım şey gibi! Bununla ilgili bir sorun yaşıyorum ve bana yardım etmeni umuyordum.
Kodunuzu, "DateDiff" işlevinin son satırındaki değişkenleri değiştirerek bir şey olana kadar olan gün sayısını hesaplamak için biraz değiştirdim;

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

Ancak, aradaki farkı doğru bir şekilde ifade edebilmesini sağlayamıyorum. Örneğin bu tarihle (biçim gg/AA/yyyy);

12.30.2011

Doğru hesaplıyor, ancak bu tarihle (aynı biçim)

10.12.2011

12 Eki 2011 yerine 10 Aralık 2011 gibi hesaplar.
"JulianStartDate" değişkenindeki gün ve ay değerlerinin konumlarını değiştirmeyi denedim;

<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)"/>

Ve bu, ikinci tarihle ilgili sorunu düzeltti, ancak ilk tarih için yanlıştı!
Ayrıca, FormatDateTime'ın son parametresinde (örneğin ddMMy, MMddyy) Avrupa LCID'lerini ve çeşitli değişiklikleri kullanmak için FormatDateTime çağrılarını, alt dize konumsal parametrelerinde başarılı olmadan uygun ayarlamalarla değiştirmeyi denedim.
Önerebileceğiniz tavsiyeler için çok teşekkür ederim.
Teşekkürler
Chris

Kod
Yok 21.09.2011 04:27
XSL dilini anlamak herkese uygun olmadığı için XSL'nin "kodsuz" bir çözüm olarak nitelendiğini düşünmüyorum, ancak programlamayı içermez. Bunun yanı sıra: Güzel çözüm, teşekkür ederiz!