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
Abbildung 1: ASPxEditor mit RequiredFieldValidator

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

Zurück

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
Abbildung 1: Mehrere Versionen auf Patchlevel - Ebene

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

Zurück

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

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.

 

Zurück

Translate this page

Kategorien

  • [-].NET Development (215)
  • [-]Datenbank (26)
  • HTML (1)
  • Konfiguration (12)
  • Mind Map (10)
  • Off-topic (9)
  • Open Source (3)
  • Qualität (7)
  • Sharepoint (6)
  • Sicherheit (2)

Archiv

Social Bookmarking

Bookmark bei: Mr. Wong Bookmark bei: Webnews Bookmark bei: Icio Bookmark bei: Oneview Bookmark bei: Linkarena Bookmark bei: Favoriten Bookmark bei: Seekxl Bookmark bei: Favit Bookmark bei: Social Bookmarking Tool Bookmark bei: Power Oldie Bookmark bei: Bookmarks.cc Bookmark bei: Newskick Bookmark bei: Newsider Bookmark bei: Linksilo Bookmark bei: Readster Bookmark bei: Folkd Bookmark bei: Yigg Bookmark bei: Digg Bookmark bei: Del.icio.us Bookmark bei: Reddit Bookmark bei: Simpy Bookmark bei: StumbleUpon Bookmark bei: Slashdot Bookmark bei: Netscape Bookmark bei: Furl Bookmark bei: Yahoo Bookmark bei: Spurl Bookmark bei: Google Bookmark bei: Blinklist Bookmark bei: Blogmarks Bookmark bei: Diigo Bookmark bei: Technorati Bookmark bei: Newsvine Bookmark bei: Blinkbits Bookmark bei: Ma.Gnolia Bookmark bei: Smarking Bookmark bei: Netvouz Information