Zur Zeit wird gefiltert nach: DevExpress
Filter zurücksetzen
ASPxEditors und Page.Validate()
Die ASPxEditors von DevExpress kommen mit einem eigenen Validierungsmechanismus daher, der sich nicht in das ASP.NET – Modell einfügt. Bei bestehenden Projekten kann das sehr schnell zu einem Fallstrick werden. In der Regel bin ich daran gewöhnt mit Page.Validate zu arbeiten, damit auf der Serverseite die Eingaben validiert werden. Die ASPxEditors werden mit dieser Methode jedoch nicht überprüft, was bei Wartungsarbeiten an bestehenden Projekten schnell einen Mehraufwand zur Folge haben kann.
Die erste Variante wäre also auf das ASP.NET – Modell zurückzugreifen und die Standardvalidatoren zu nutzen. Als Beispiel nehme ich die Textbox, obwohl die ASPxComboBox bzw. das ASPxDateEdit - Control besser dafür geeignet wären.
Mit dieser Variante bettet sich die Validierung in das Standardkonzept ein. Ein Problem dabei ist der Aufwand die Elemente zu stylen. Die ASPxEditors erzeugen eine Tabelle und dadurch ist das Verhalten in der Darstellung anders. Während die Fehlermeldung bei der Standard-Textbox neben dem Eingabefeld angezeigt wird, ist es bei der ASPxTextBox unterhalb auf einer neuen Zeile.
C#
namespace Custom.Web.UI.WebControls
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web.UI;
public class TestTextBox : DevExpress.Web.ASPxEditors.ASPxTextBox, IValidator
{
#region IValidator Member
public string ErrorMessage
{
get
{
return this.ErrorText;
}
set
{
this.ErrorText = value;
}
}
#endregion
protected override void OnInit(EventArgs e)
{
if (this.Page != null)
{
this.Page.Validators.Add(this);
}
base.OnInit(e);
}
protected override void OnUnload(EventArgs e)
{
if (this.Page != null)
{
this.Page.Validators.Remove(this);
}
base.OnUnload(e);
}
}
}
DevExpress Changes
Die Komponenten von DevExpress haben die klassische Versionsnummer die sich aus Hauptversion, Nebenversion und Revisionsnummer (Patch) zusammensetzt. Nehmen wir als Beispiel 9.2.6.
In der Regel können aus der Versionsnummer folgende Informationen gezogen werden:
- Erhöht sich die Hauptversion, handelt es sich um eine neue Version des Programms.
- Erhöht sich die Nebenversion, wurden neue Funktionalitäten hinzugefügt oder geändert.
- Erhöht sich die Revisionsnummer, wurden Fehler beseitigt.
Diese Theorie ist nicht neu, die Praxis hat jedoch ihre Tücken. Mit dem Wechsel des ASPxGridViews von Version 9.2.6 auf 9.2.8 wurde ein Fehler korrigiert. Mit dieser Fehlerbeseitigung war es anschliessend nicht mehr möglich, im Event RowPrepared Einfluss auf die Zellen zu nehmen. Aus Sicht des Supports war die Begründung, dass mein Code ab Version 9.2.8 fehlerhaft sei, aus meiner Sicht wird in diesem Bereich nicht mehr die Erwartungskonformität erfüllt. Das hat zur Folge, dass sich der Lernaufwand erhöht, weil ich nicht mehr von den Standard-Komponenten ableiten kann, sondern die Dokumentation lesen muss. Beim ASPxGridView ist das „Hinterhältige“ dabei, dass man weiterhin auf die Zellen zugreifen und die Eigenschaften ändern kann, es hat jedoch keine Auswirkungen auf die Ausgabe mehr.
Der zweite Aspekt, solche Probleme tauchen immer dann auf, wenn Termindruck besteht. Es stellt sich dann die Frage: Quellcode überarbeiten oder neue Funktionen implementieren. Eine Variante könnte dann sein: Quellcode überarbeiten, wenn die Zeit dazu besteht. Damit dies schrittweise auch gemacht werden kann, müssen in diesem Fall die Versionen 9.2.6 und 9.2.8 auf dem Entwicklungsrechner installiert sein. Das Setup lässt aber diese Möglichkeit auf Patchlevel – Ebene nicht zu.
Damit dies doch möglich wird, werden die Komponenten der Vorgängerversionen benötigt und in ein separates Verzeichnis gespeichert. Anschliessend werden die benötigten Komponenten wieder im Global Assembly Cache installiert. Das Verzeichnis mit den Komponenten wird beim Schlüssel AssemblyFolders in der Registry aufgenommen. Die Anleitung der Vorgehensweise ist hier beschrieben.
Diese Vorgehensweise erfordert jedoch Disziplin, damit es nicht zu einem Versionsdurcheinander in der jeweiligen Projektmappe kommt.
ASPxEditors ganz Gross
Als ich mein erstes Webprojekt mit der ASP.NET Suite erstellt habe, staunte ich nicht schlecht über den Umfang des produzierten HTML-Code. Mein erster Gedanke war: "Wo ist denn hier CSS-Layout". Mit diesem Gedanken bin ich nicht allein, wenn ich mir so die Supportdatenbank von DevExpress anschaue.
Die ASPxEditors haben den Nachteil, dass sie viel HTML erstellen. Um den Umfang zu minimieren wird auch häufig empfohlen, die Controls im Native-Mode zu verwenden, aber das ist nicht die optimale Lösung für mich. Die 2. Variante ist HTML-Komprimierung, die auf jeden Fall in Betracht gezogen werden sollte.
Dieser Umstand hat auch Auswirkungen bei der Planung des Benutzerinterface.
Aus diesem Grund habe ich mir eine kleine Übersicht zusammengestellt, damit ich beim Papier-Prototyping in den Meetings eine Ahnung habe, was da auf mich zukommen wird.
Control | Einstellung | HTML Size |
|---|---|---|
ASPxTextBox | Native | 82 Bytes |
ASPxTextBox | Native/ClientSideAPI | 720 Bytes |
ASPxTextBox | Native/ClientSideAPI/Validation | 1'707 Bytes |
ASPxTextBox | ClientSideAPI/Validation | 2'649 Bytes |
ASPxButton | Native | 650 Bytes |
ASPxButton | 1'713 Bytes | |
ASPxCalendar | 13'645 Bytes | |
ASPxCalendar | Validation | 14'853 Bytes |
ASPxCheckBox | 831 Bytes | |
ASPxColorEdit | 7'688 Bytes | |
ASPxColorEdit | Validation | 8'838 Bytes |
ASPxComboBox | Native | 1'373 Bytes |
ASPxComboBox | Native/Validation | 2'297 Bytes |
ASPxComboBox | 5'412 Bytes | |
ASPxComboBox | Validation | 6'462 Bytes |
ASPxDateEdit | 18'030 Bytes | |
ASPxDateEdit | Validation | 19'273 Bytes |
ASPxDateEdit | PopupCalenderOwnerID | 1'833 Bytes |
ASPxMemo | Native | 104 Bytes |
ASPxMemo | Natvie/Validation | 1'676 Bytes |
ASPxMemo | 1'326 Bytes | |
ASPxMemo | Validation | 2'345 Bytes |
Die Übersicht enthält nicht alle Controls, sondern nur jene die ich in den Projekten am häufigsten verwendet habe. Die Grösse bei der ASPxComboBox bezieht sich lediglich auf das Grundgerüst ohne Einträge.








Social Bookmarking