Kod yok çözümü: Liste öğesinin son değiştirilme tarihinden bu yana geçen günleri görüntüleme

Justin Joyce, LANtek tarafından

Genel bakış: Kod içermeyen özel yaşlandırma raporları

SharePoint sitesinin en çok istenen işlevsel parçalarından biri de görevler veya liste öğeleri için yaşlandırma raporudur. Başka bir deyişle, bu liste öğesinin en 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 öğeler için tarihlerimiz var, öğelerde belirli değişikliklerin olay alıcıları aracılığıyla gerçekleştiği özel tarihleri saklama yeteneğine sahibiz. Bilgilerimizle çalışmak için Excel benzeri formüller ekleyebileceğimiz hesaplanmış sütunlarımız var. Bu oldukça basit bir öneri gibi görünüyor. Bir tarih alanı seçiyoruz, hesaplanan sütun oluşturuyoruz ve sonra [DateField] – [Bugün] satırları boyunca bir formül yapıyoruz. Ah, o kadar hızlı değil! Bu "basit" görevi deneyen herkesin bildiği gibi, hesaplanan bir sütunda [Bugün] gibi bir şey kullanmaya çalışmak sorunlara neden olur. Hesaplanan sütununuzun formül kutusuna [Bugün] öğesini eklemeyi denediğinizde, aşağıdakine benzer bir hata iletisi alabilirsiniz:

Bunun nedeni nedir? Bu, hesaplanmış sütunların hesaplanma şekliyle ilgilidir.

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

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

Bütün bunlar, Sütun1 Sütun2'den küçük veya ona eşitse Tamam görüntüle, aksi halde Tamam Değil görüntüle diyor. Bu, hesaplanan bir sütun için oldukça tipik bir temel formüldür ve bu sütunları içeren liste öğesiyle ilgili temel bir varsayımda bulunur: Sütun1 ve Sütun2 değerleri, liste öğesinde bir Update olayı olmadan hiçbir zaman değiştirilemez.

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

Hesaplanan sütunların bu şekilde işleyeceğine karar verdikleri toplantıda değildim, ancak eğitimli bir tahminde bulunmam gerekirse, performans için bu şekilde çalıştıklarını varsayardım. Her biri "canlı" bir güncelleştirme gerektiren hesaplanmış bir sütun içeren birkaç bin öğeden oluşan bir listeniz olduğunu düşünün. Bu, bir mekanizmanın, belki de bir zamanlayıcı işinin, hesaplanan sütunu içeren her öğeyi sık sık yinelemesi ve değerini güncelleştirmesi gerektiği anlamına gelir. Bu, performans açısından son derece yorucu olabilir, çünkü daha büyük dağıtımlarda bu iş sürekli olarak çalışıyor ve bir şeyleri değiştiriyor olabilir. Bu sadece benim tahminim, ama düşünürseniz oldukça mantıklı.

Önce Bugün adlı bir sütun oluşturup ardından formülünüze ekleyip silerek SharePoint'i kandırarak Bugün değerini kabul etmesi için kandırmayı içeren, benzer çözümlerle ilgili bazı öneriler vardır. Bunların hepsi iyi, güzel, ama hesaplanmış sütunların ne zaman güncelleştirildiğiyle ilgili dediğimi unutmayın. Bu değer yalnızca öğe güncelleştirildiğinde değişir ve bu da, özellikle gün hesaplaması söz konusu olduğunda, değerlerinizin kısa süre sonra yanlış olacağı anlamına gelir.

Değerleri sayfaya yazmak için akıllı JavaScript kullanan başkalarını gördüm. Bu da işe yarayacaktır, ancak kaçınılabildiğinde kategorik olarak istemci komut dosyasına karşıyım.

Uygulama:

Peki ne yapmalı? Bugün gibi "geçici" olarak adlandırılan işlevler için hesaplanmış sütunlar söz konusu değildir. Hesaplanan Sütun, zamanlayıcı işi veya bu hesaplamanın yapılmasını gerektiren her bir öğeyi güncellemek için zamanlanmış bir işlem gibi bunu bizim için halledecek bazı özel kodlar geliştirmemiz mümkündür. Bu bizi son paragrafta bahsettiğim performans sorununa geri getiriyor ve ayrıca söz konusu siteye/listeye/sütuna son derece spesifik olacak kırılgan bir çözüm. Bu iki endişenin yanı sıra, benim gibi kodlamayı bilen ve onu sizin için bu çözümü geliştirmeye ikna eden inek bir adam bulmanız gerekir. Ama daha kolay bir yolu var!

Alan oluşturma ve sitenizdeki sayfaları düzenleme haklarınız varsa ve XSLT ve görünüm oluşturma hakkında biraz bilginiz varsa, liste görünümüne eklenebilecek ve sayfadan her istendiğinde değerinizi aslına sadık olarak hesaplayacak bir XSL şablonu oluşturabilirsiniz. Bu senaryo, performansla ilgili endişelerimizi ortadan kaldırır ve bir çözüm aracılığıyla özel kod geliştirilip dağıtılmasını gerektirmez.

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

1. Kaynağımız olarak görev yapacak alanı oluşturun veya seçin. Tarih türünde olmalıdır.
2. Hesaplanan değer için yer tutucu görevi görecek alanımızı oluşturun.
3. Bu alanların her ikisini de bir içerik türüne ekleyin ve o içerik türünü de 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 Stil Kitaplığı'na yükleyin.
6. Kullanıcı arabirimi aracılığıyla Liste Görünümü Web Bölümünün "XSL Bağlantısı" özelliğini ayarlayın.
7. Başarılı!

Şimdi örnek bir kullanım durumunu inceleyelim ve uygulamayı gözden geçirelim. Müşterimiz, kendisine belirli bir liste öğesinin durumunda ne kadar süredir beklediğini bildiren bir ana liste görünümü 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ının her değiştirilişini yakalayan ve bu tarihi "Durum Değişti" adlı bir sütuna kaydeden bir olay alıcısı zaten vardı. Tüm bu kablolama gerekli değildir ve HERHANGİ bir tarih alanıyla yapılabilir (bu bizim uygulamamızdır, ancak denemekten çekinmeyin). İhtiyacınız olan en az şey, hesaplamanızı listenize eklemek için kaynak tarih alanınız ve yer tutucu alanınızdır (bir sonraki paragrafta daha fazlası), ancak bu çözümü sitenizdeki başka yerlerde yeniden kullanmak istemeniz durumunda site sütunlarını ve site içerik türlerini kullanmanızı öneririm.

Dolayısıyla, bugünün tarihine karşı hesaplamamızda kullanabileceğimiz kaynak tarihimiz var. Şimdi hesaplanan değerimiz için kapsayıcı olarak kullanmak üzere özel bir site sütunu oluşturabiliriz. Bu durumda, yeni veya düzenleme öğesi formlarında değiştirilemeyeceği için hesaplanan bir sütun kullanmayı seçtim, 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 vb. neden görüntülenmediği konusunda kafa karıştırıcı olabilir.

Artık site sütunumuz olduğuna göre, listemizde kullanılacak içerik türlerimize ekleyebiliriz. Ardından, daha sonra XSLT'miz ile özelleştirilecek olan görünümümüzü oluşturmamız gerekiyor. Kaynak tarih sütununuzu ve hesaplanan değer için yer tutucu işlevi görecek 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 gereken her şeye sahibiz. 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 bazı normal SharePoint tarafından oluşturulan işaretlemenin yanı sıra bunun belirli bölümlerini geçersiz kılmak ve bizim için istediğimiz değeri hesaplamak için kullanılan kendi özel işaretlememizi içerecektir.

Kredinin vadesi geldiğinde kredi vererek, bu çözüm için kullandığım gerçek hesaplamaları yapmak için XSL şablonları, MSDN forumlarında nezaketle "girdap" tarafından sağlandı:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

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

Bunu en sevdiğiniz metin düzenleyicide açtığınızda, görünümleri işlemek için çok sayıda normal SharePoint XSL işaretlemesi göreceksiniz, 357. satıra kaydırmaya devam ederseniz, işaretlemeye eklediğim özel şablonların başlangıcını göreceksiniz, ilki "DateDiff" şablonu, ardından "calculate-julian-day" ve "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Bunlar, hesaplamalarımızı görünümlerimizde yapacak ve gösterecek üç şablonumuzdur. 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 alanın görünen adı değil, İÇ adını kullanmak isteyeceğinizi unutmayın.

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

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üzü bulun ve sağ üst köşedeki küçük, aşağı dönü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, tarayıcı pencerenizin sağ tarafında 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.

Stiller Kitaplığınızda daha önce kopyalamış olduğunuz XSL dosyanızın bağlantısını yapıştırın (bu göreli veya mutlak bağlantı olabilir).

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

Her şey doğru yapılandırıldıysa, artık "Durumdaki Gün Sayısı" sütununuzda sayıları görüyor olmalısınız.

Ve son olarak, çeşitli tarihlerdeki bazı test verileriyle nasıl görüneceği:

Özet:

İşte burada: SharePoint'te yaşlandırma raporu oluşturmak için güzel biçimlendirilmiş, sağlam ve daha iyi performans gösteren bir yol. Bunun, burada incelediğimiz bir kullanım durumu dışında epeyce potansiyel uygulaması vardır. Bu tür raporlarla ilgili bir diğer yaygın senaryo, bir bakışta görevin oluşturulmasının üzerinden ne kadar zaman geçtiğini görebilmek için raporu görev listesine eklemektir.

Keyfini çıkarın!

--Hüseyin

Justin Joyce, LANtek

Açıklamalar

Eksik adımlar
8/10/2012 03:51
Tamam adımları takip ettim, ancak eksik bir şey olmalı - XSL hangi tarihi kullanacağını veya o tarihten bu yana geçen günleri hangi alana ekleyeceğini nasıl bilecek? Adım kaçırıldığında bundan nefret edin.

Kodsuz, kabul edildi!
30.08.2012 12:12
Katılıyorum - bunun gerçekten "kod yok" olarak sayıldığını düşünmüyorum.
İlginç bir şekilde, SharePoint'in bazı hatalarıyla, Bugün'ü kullanan çalışan bir hesaplanan sütunum var... nasıl veya neden olduğundan emin değilim çünkü tekrar yapmasını sağlayamıyorum, ama hala orada ve çalışıyor.

"Durumdaki Gün Sayısı" Hesaplanan Sütunu Formülü?
2/05/2012 07:39
Hüseyin - "Durumdaki Gün Sayısı" hesaplanan site sütununuz (yer tutucu sütun) için kullandığınız formül nedir? "=bugün" müydü?

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

Harika yazı
30/11/2011 09:53
Merhaba,
Harika yazı.
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ürler.

Ynt: Kod yok çözümü: SharePoint listesi öğesinin son değiştirilme tarihinden bu yana geçen günleri görüntüleme
11/10/2011 08:24
Merhaba Chris.
Harika bulmak!
Bugün daha sonra umarım yayınladıklarınıza bir göz atacağım ve bu çözümü biraz daha sağlam hale getirip getiremeyeceğimi göreceğim.
Gönderiyi beğenmenize sevindim ve Avrupa tarih formatına bir çözüm bulabildiğinize çok sevindim. :)
-Hüseyin

Avrupa tarih biçimleri çözümü
11/10/2011 06:45
Tekrar merhaba Justin,
Bilginize, bu sayfada daha önce bahsettiğ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 son iki günümü aradığım türden bir şey! Ancak, bununla ilgili biraz sorun yaşıyorum ve bana yardım edebileceğinizi umuyordum.
"DateDiff" işlevinin son satırındaki değişkenleri değiştirerek o zamandan beri değil, bir şey olana kadar olan gün sayısını hesaplamak için kodunuzu biraz değiştirdim;

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

Ancak, aradaki farkı yalnızca zamanın yarısında doğru bir şekilde hesaplamasını sağlayabiliyorum. Yani örneğin bu tarihle (gg/AA/yyyy formatında);

30/12/2011

Doğru olarak hesaplanır, ancak bu tarihle (aynı biçimde)

12/10/2011

12-Eki-2011 yerine 10-Ara-2011 gibi hesaplanır.
"JulianStartDate" değişkenindeki gün ve ay değerlerinin konumlarını şu şekilde değiştirmeye çalıştım;

<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 daha sonra ilk buluşma için yanlıştı!
Ayrıca, Avrupa LCID'lerini kullanmak için FormatDateTime çağrılarını değiştirmeyi ve FormatDateTime'ın son parametresinde (ör. ggMMyyyy, MMddyyyy) çeşitli değişiklikleri, alt dize konumsal parametrelerinde uygun ayarlamalarla başarılı olmadan değiştirmeyi denedim.
Sunabileceğiniz herhangi bir tavsiye için çok minnettar olurum.
Teşekkürler,
Hasan

No-Code
21/09/2011 04:27
XSL dilini anlamak herkes için olmadığı için XSL'nin "kodsuz" bir çözüm olarak nitelendirildiğini düşünmüyorum - ancak programlamayı içermiyor. Bunun yanı sıra: Güzel çözüm, teşekkürler!