DevExpress AspxGridView filtrowanie w zakresie dat/liczb od-do

O ile standardowy devexpress aspxgridview nie posiada domyślnie wbudowanego filtru wyboru daty w zakresie od-do (standardowo można wybrać datę z kalendarzyka w 'popupie', lub z góry zdefiniowane wartości 'przedziału' jako 'drop down list') to od czego mamy support i genialne wręcz możliwości rozszerzania domyślnej funkcjonalności jakie oferują nam kontrolki devexpressa.

Zakres filtrów z datami 'od-do' został opisany w tym oto zgłoszeniu supportu, natomiast utworzenie odpowiedniego filtru dla wartości numerycznych jest bliźniaczo podobne poprzez utworzenie klasy
NumericSelector , która jest klasą bliźniaczą klasy DateSelector.

Usuwanie elementu kolekcji podczas iterowania po tej kolekcji.

Kolekcje dynamiczne w jakie wyposażone są języki c# oraz java to wielki krok na przód w porównaniu do standardowego języka c++. Oczywiście w c++ były tablice i wskaźniki, a rozszerzeniach języka c++ kolekcje, jednak operowanie na dynamicznych listach z punktu widzenia programisty jest dużo bardziej wygodne i bezpieczne na kolekcjach niż na tablicach (ehh, te wskaźniki). Główna zaleta kolekcji polega bowiem na tym, że dynamicznie zmieniają one swoją objętość podczas dodawania i usuwania elementów. Takie zachowanie ma mnóstwo plusów, ale ma też jeden minus, tj. jeżeli iterujemy pętlą po kolekcji generycznej w standardowy sposób (od elementu 0, do elementu n) to usuwając elementy z listy, dynamicznie zmniejszamy jej wielkość, a co za tym idzie pętla będzie próbowała się odwołać do większej ilości elementów niż jest w kolekcji, a to spowoduje wystąpienie wyjątku. Oczywiście jest na to prosty i wygodny sposób, tj. iterowanie po kolekcji 'od tyłu'. Rozwiązanie zaczerpnięte z forum stackoverflow.com

var list = new List<int>(Enumerable.Range(1, 10));
for (int i = list.Count - 1; i >= 0; i--)
{
    if (list[i] > 5)
     list.RemoveAt(i);
}
list.ForEach(i => Console.WriteLine(i));

Odwołanie się do kontrolki DevExpress za pomocą javascript

Jednym z ważnych aspektów pisania efektywnego i przyjaznego dla użytkownika kodu aplikacji webowych, jest umiejętne wykorzystywanie języka javascript umieszczonego w przeglądarce. Aby efektywnie korzystać z tego języka, należy umieć odwoływać się do obiektów.
Standardowo, w języku javascript do obiektów dokumentu odwołujemy się poprzez metodę 'document.getElementById()':

<dx:ASPxButton ID="ASPxButton1" runat="server" AutoPostBack="False" Text="Get text">
</dx:ASPxButton>

<script type="text/javascript" >
     var editorClientId = "<%=ASPxButton1.ClientID%>";
     var editor = document.getElementById(editorClientId);
     //Do something
</script>

Niestety, ale taka, standardowa dla języka javascript opcja, w przypadku kontrolek DevExpressa nie zadziała. W przypadku kontrolek DevExpressa, aby odwołać się do naszych kontrolek w języku javascript mamy dwie możliwości:

a) nadać kontrolce sztywne 'client id', tak jak zostało to opisane w tej odpowiedzi supportu.. Niestety takie rozwiązanie ogranicza nas do jednej instancji tej kontrolki na stronie:

<dx:ASPxPopupControl ID="ASPxPopupControl1" runat="server" ClientInstanceName="popupControl" ></dx:ASPxPopupControl>

 <script type="text/javascript" >
  popupControl.Show();
 </script>

b) wykorzystać metodę 'ASPxClientControl.GetControlCollection().GetByName()', która jest DevExpressowym odpowiednikiem 'document.getElementById()'. Sposobów jak to zrobić jest kilka. Jeden z nich umieszczony został w dokumentacji. Inny przykład:

        <dx:ASPxGridView ID="grid" runat="server" CssClass="gridRelatedDocs" AutoGenerateColumns="False" Width="100%"
        GridLines="None" style="padding-left: 0px;padding-right: 0px;">
            <Border BorderStyle="None" BorderWidth="0px" />
            <SettingsBehavior AllowDragDrop="False" />
            <Settings ShowFilterRow="True" />
            <SettingsPager >
                <Summary Visible="False" />
            </SettingsPager>
        </dx:ASPxGridView>

<script language="javascript" type="text/javascript">
    function DoSomething() {

        var grid2 = $('.gridRelatedDocs');
        if (grid2 != null && grid2[0] != null) {
            var grid = ASPxClientControl.GetControlCollection().GetByName(grid2[0].id);
            //grid.DoSomething
        }
    }
 </script>

Generalnie sposób nr. 2 jest bardziej przyjazny i uniwersalny. Wprawdzie najpierw musimy ustalić id elementu w hierarchii struktury drzewa DOM, ale posiadając już standardowy, 'javascriptowe' id obiektu możemy się nim posługiwać w standardowy sposób. Wykorzystanie rozwiązania z 'ASPxClientControl.GetControlCollection().GetByName'  pozwala na umieszczenie wielu kontrolek tego samego typu na jednej stronie asp.net.

Wstep do kontrolek DevExpress

Jak zapewne wielu programistów wie, jedną z najgorszych rzeczy, jakie można robić będąc programistą, to wymyślanie koła od nowa. Aby tego nie robić, powstały frameworki (np. .NET Framework), wzorce projektowe, rozszerzalne biblioteki (np. jQuery, pdf-libraries) i wiele, wiele innych. Część udostępnianych na darmowych licencjach (np. Licencja X11 (MIT)), a część na licencjach komercyjnych.
Takim przykładem komercyjnego oprogramowania, a dokładniej kontrolek wykorzystywanych w środowisku '.NET' są kontrolki firmy  DevExpress. Kontrolki, które nie są tanie (link do cennika) i kupowane są 'per developer'. Tak, moi mili. Te ceny, które są tam umieszczone dotyczą ceny, za możliwość wykorzystywania oprogramowania przez pojedyńczego programistę i kształtują się od $900 za najmniejszy pakiet (np. dla programisty asp.net) do pakietu full ($2199 per programista).

Co za tą cenę dostajemy?
Hmmm, chyba najlepsze kontrolki programistyczne, jakie można dostać w .net ;)
Programując z ich wykorzystaniem programista naprawdę zyskuję sporą przewagę nad rozwiązaniami darmowymi, a co za tym idzie programowanie idzie szybciej, sprawniej, jest ładniejsze i zawiera mniej błędów. Przede wszystkim uzyskujemy kod wykorzystywany i sprawdzony przez miliony ludzi. Firma devExpress wygrywała ze swoimi kontrolkami wiele międzynarodowych konkursów, przez co jej popularność rosła, a wraz z nią ilość ludzi którzy bezpośrednio (developerzy) oraz pośrednio (użytkownicy ich programów) z nich korzystali na co dzień. Jedną z największych zalet wynikających z tych kontrolek jest właśnie to, że jak coś się miało popsuć, lub 'nie wyjść' to bardzo prawdopodobne, że wcześniej popsuło się komuś innemu i ekipa z devxpressa już ten problem rozwiązała, lub właśnie nad nim pracuje ;)
Oczywiście, nie ma róży bez kolców, ale o tym nieco później.

Najpierw jednak przyjrzyjmy się tym kontrolkom nieco bliżej. Jak przykład użyję kontrolek asp.net, jako, że są to kontrolki webowe i istnieje całkiem niezłe 'on-line' demo. Jedną z najlepszych, a zarazem najczęściej używanych jest DevExpressowy odpowiednik AspxGridView.
Zalecam zapoznanie się z demem tego grida, ponieważ posiada naprawdę potężne możliwości (np. utworzenie rozwiązania, wyświetlającego 300.000 rekordów w kilka min. z rewalacyjną, jak na taką ilość danych szybkością wyświetlania, sortowania, filtrowania itp.).

Do tego dochodzą wszelakie możliwości kontrolek DevExpressa, czyli multum opcji i pełna konfigurowalność (a w pakiecie ultimate również kody źródłowe kontrolek). Po tym, jak programista zobaczy, ile jest opcji konfiguracyjnych dla danej kontrolki by deafult (a drugie tyle w tutorialach i Q&A na forum wsparcia) to później zwykłe .net-owe kontrolki wyglądają mega blado.

Tak jak już zostało wspomniane, aspxGridView nie jest jedyną kontrolką, jaka isntieje w pakiecie. Generalnie zasada jest taka, że każda kontrolka wystepująca w standardowym GUI .NET Framework ma tutaj swoje devExpressowego odpowiednika. Do tego dochodzą jeszcze inne, mniej lub bardziej przydatne kontrolki standardowo nie występujące we frameworku.

Ale nie ma róży bez kolców. Oto kilka mniej przyjemnych aspektów, które należy wziąć pod uwagę w momencie, gdy nastąpi już pierwszy 'efekt wow'.
Więc po kolei:
- cena, która jest dosyć spora, bo liczona per programista
-  problemy z instalacją w środowisku sharepoint - zapewne będzie to temat jednego z przyszłych wpisów. Generalnie udało nam się to zwalczyć własnymi siłami dla pojedyńczego serwera, za pomocą ręcznego instalowania paczek '.wsp' oraz ręcznych wpisów do web.config (automaty dostarczane przez producenta nie zadziałały, a wsparcie techniczne nie było nam w stanie pomóc), aczkolwiek syt. 'farmy serwerów', w której mamy dostęp do pliku web.config tylko jednego serwera nadal jest dla nas problematyczna.
- na słabszych sprzętowo maszynach,  obciążenie procesora/pamięci ram powodowało randomowe błędy krytyczne visual studio powodujące jego zamknięcie w trybie awaryjnym, w momencie włączania debuggera. O dziwo, problem ten występował tylko i wyłącznie dla aplikacji typu sharepoint.
- takie sobie wsparcie techniczne, które stara się pomóc, jednak z własnego doświadczenia wiem, że iż mimo, że jest całkiem miłe, to działa średnio sprawnie.


Generalnie temat warty rozważenia, aczkolwiek w przypadku firm typowo sharepointowych mocno wątpliwy, z uwagi na dodatkowe, mało znane producentowi problemy związane z developowaniem tych kontrolek w środowisku sharepoint.

Kilka wersji biblioteki jQuery na tej samej stronie

jQuery jest bardzo fajną i przydatną biblioteką javascriptową. Standardowo posiada jednak pewną wadę. W momencie, gdy kilka komponentów umieszczonych na stronie próbuje wczytać swoje biblioteki jQuery, wyrzuca dziwne błędy (jQuery przestaje działać częściowo lub w całości). Jest to związane z faktem, że system nie wie, do której konkretnej biblioteki ma się odwołać poprzez znacznik '$'. Jak uniknąć błędów, związanych z faktem, że na stronie może być umieszczony jeden lub kilka niezależnych komponentów, a każdy z nich niezależnie wymaga do działania biblioteki jQuery opisałem w jednym z poprzednich wpisów na blogu.

Życie jednak pokazuje, że czasami jesteśmy zmuszeni do wykorzystania na jednej stronie asp.net kilku bibliotek jQuery w różnej wersji biblioteki. Np. do 95% syt. chcemy wykorzystywać bibliotekę w wersji "stabilnej', natomiast do 5% syt. chcemy wykorzystać najnowszą funkcję biblioteki dostępnej jedynie w niestabilnej wersji biblioteki. Na szczęście biblioteka jQuery pozwala na zastosowanie takiego rozwiązania.

<script src="/_layouts/scripts/jquery-1.8.2.min.js" type="text/javascript"></script>

<script src="/_layouts/scripts/jquery-ui-1.8.24.custom.min.js" type="text/javascript"></script>

<script type="text/javascript">

//<![CDATA[

var j182 = $.noConflict(true);$(document).ready(function(){                     

                        j182("#featured").tabs().tabs("rotate", 5000, true);

                        });//]]>

</script>

dodatkowo, po stronie kodu c# wpisujemy:

            if (!cs.IsClientScriptBlockRegistered("j182"))

                cs.RegisterClientScriptBlock(this.GetType(), "j182", @"var j182 = $.noConflict(true);", true);


W tym przypadku, mamy wczytane 2 biblioteki jQuery. Do pierwszej, w wersji 1.8.2 odwołujemy się normalnie, tj. poprzez znacznik '$', natomiast do drugiej, w wersji 1.8.24 poprzez znacznik przez nas zdefiniowany, tj. poprzez znacznik 'j182'.

Powershell a sharepoint

System Windows, podobnie jak system Linux posiada własny odpowiednik konsoli (terminala) administratora, w którym można uruchamiać polecenia oraz skrypty, za pomocą których administrator posiada pełną władzę nad systemem. W systemie Windows, interpreter poleceń wykorzystywany przez konsolę, oraz powiązany z nim język nazywa się Windows_PowerShell.

W teorii "Powershell" zapewnia administratorowi wszystkie dostępne opcje administracyjne, które może on wykonać zarówno z poziomu linii komend, jak i poprzez przygotowane wcześniej skrypty. Pełny i praktyczny poradnik, od czego warto zacząć podczas nauki obsługi "Powershella", można znaleźć jako odpowiedź na jedno z pytań, zamieszczonych na forum stackoverflow.com.

Podczas pisania skryptów, dobrze jest mieć "kolorowanie składni", co zapewni nam Powergui.

Skoro już mamy za sobą wstęp teoretyczny, narzędzie do kolorowania składni (aczkolwiek same skrypty zawsze możemy pisać w notatniku), oraz info, gdzie możemy zdobyć więcej praktycznych informacji o samym PowerShellu możemy przejść do analizowania interesującego nas zagadnienia czyli modyfikacja witryny sharepoint za pomocą skryptu powershell.
Utwórzmy wiec skrypt, który będzie pobierał 3 parametry (adres witryny, nazwę tabeli, nazwę pola), a nast. zmieńmy jedno z jego właściwości, np. wymagalność tego pola.

param

(

      [string] $portalURL = $(Throw "Missing 'portalURL' parameter"), #required parameter

      [string] $listName = $(Throw "Missing 'listName' parameter"), #required parameter

      [string] $fieldName = $(Throw "Missing 'fieldName' parameter") #required parameter

)

#komentarze pisze się z haszem na początku

$web = Get-SPWeb $portalURL;

$list = $web.Lists[$listName];

$field = $list.Fields.GetFieldByInternalName($fieldName);

[bool]$fvalue = $field.Required;

if ($fvalue) {

      $field.Required = 0;

      $field.Update();

      $list.Update();

} else {

      $field.Required = 1;

      $field.Update();

      $list.Update();

}

$web.Dispose();

 Jak widać, skrypt jest bardzo prosty. Na samym początku podajemy parametry, wykorzystywane przez skrypt  oraz określamy ich typ (sekcja 'param'). Nast. pobieramy SpWeba, listę SpList i pole SpField, po czym sprawdzamy jego wartość, a nast. zmieniamy jego wartości i wykonujemy update. Na sam koniec pobranego SPWeb'a musimy disposować. Dla programisty sharepoint ten kod wyda się dziwnie znajomy (tylko delikatnie nieco inna składnia).
To co jest WAŻNE, to aby zapisać skrypt w pliku tekstowym z rozszerzeniem *.ps1.

Wywołanie tego kodu, nast. poprzez: "Start->Microsoft Sharepoint 2010 Products -> Sharepoint 2010 Managment Shell"

A nast. w konsoli odpalamy utworzony przez nas skrypt wg. schematu: .\nazwaSkryptu.ps1 -parametrNr1 "ParametrNr1" -ParametrNr2 "ParametrNr2 -ParametrNr3 "ParametrNr3"

W przypadku większej ilości parametrów, zamiast podawać wszystkie parametry z konsoli, lepiej jest utworzyć osobny plik .csv z parametrami i umieścić go w tym samym katalogu co skrypt, a nast. wczytać jego zawartość wewnątrz skryptu.

P.S. Inny, bardziej zaawansowany przykład wykorzystujący power shell w kontekście sharepointa.

Build Version Increment

Jednym z bardzo prostych, a zarazem przydatnych pluginów do Visual Studio jest dostępny za darmo Build version increment. Plug in służy do automatycznego zwięszania nr. wersji znajdującego się w pliku AssemblyInfo.cs.

Ważne, aby w rozwiązaniach typu sharepoint inkrementować tylko i wyłącznie "AssemblyFileVersion" (natomiast "AssemblyVersion" musi pozostać nie zmienione). W przypadku normalnych rozwiązań asp.net wolno nam modyfikować oba parametry.

Po zainstalowaniu plug-ina, uruchamiamy go z opcji dostępnych w Visual Studio. Zakładka "Tools"->"Build Version Increment Settings", a nast. w popupie wybieramy interesujący nas projekt, w którym ustawiamy zasady inkrementowania. Osobiście preferuję ustawić opcję inkrementowania w oparciu o build, a numer rewizji w oparciu o "rok, nr. dnia w roku".
Przykładowe skonfigurowane opcje wyglądają tak: