Zur Zeit wird gefiltert nach: DevExpress
Filter zurücksetzen

18.02.2010
22:48

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.

Abbildung 1: ASPxEditor mit RequiredFieldValidator
Abbildung 1

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.

Abbildung 2: Darstellung ohne float
Abbildung 2
Abbildung 3: ASPxTextBox im Native-Mode
Abbildung 3
Abbildung 4: Zusammengesetztes Control aus Label, Textbox und Validierung
Abbildung 4
Abbildung 4: Prüfung beider Validierungsmechanismen im Code-Behind
Abbildung 4
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);
    }
  }
}
Abbildung 5: ASPxTextBox mit Schnittstelle IValidate
Abbildung 5
Abbildung 6: Prüfung für Pflichteingabe
Abbildung 6
Abbildung 7: Prüfung gültige Email
Abbildung 7
08.02.2010
23:21

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.

Nachdem diese Schritte erfolgreich ausgeführt worden sind, stehen die Komponenten der Vorgängerversion wieder zur Verfügung.

Abbildung 1: Mehrere Versionen auf Patchlevel - Ebene
Abbildung 1

Diese Vorgehensweise erfordert jedoch Disziplin, damit es nicht zu einem Versionsdurcheinander in der jeweiligen Projektmappe kommt.

11.01.2010
21:15

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
ASPxTextBoxNative82 Bytes
ASPxTextBoxNative/ClientSideAPI720 Bytes
ASPxTextBoxNative/ClientSideAPI/Validation1'707 Bytes
ASPxTextBoxClientSideAPI/Validation2'649 Bytes
ASPxButtonNative650 Bytes
ASPxButton1'713 Bytes
ASPxCalendar13'645 Bytes
ASPxCalendarValidation14'853 Bytes
ASPxCheckBox831 Bytes
ASPxColorEdit7'688 Bytes
ASPxColorEditValidation8'838 Bytes
ASPxComboBoxNative1'373 Bytes
ASPxComboBoxNative/Validation2'297 Bytes
ASPxComboBox5'412 Bytes
ASPxComboBoxValidation6'462 Bytes
ASPxDateEdit18'030 Bytes
ASPxDateEditValidation19'273 Bytes
ASPxDateEditPopupCalenderOwnerID1'833 Bytes
ASPxMemoNative104 Bytes
ASPxMemoNatvie/Validation1'676 Bytes
ASPxMemo1'326 Bytes
ASPxMemoValidation2'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.

 

Translate this page

Kategorien