OptionValueManager

Diskussionen über den Quellcode (Module, Klassenstruktur, Schnittstellen u.s.w.) der Access Code Library

OptionValueManager

Beitragvon Andreas Vogt » Di 19. Mai 2015, 22:14

Hallo,
ich habe eine Klasse OptionValueManager.cls geschrieben im Zweig draft/usability.
Die Klasse ließt Feldnamen und dazugehörende Werte einer Tabelle mit Options- bzw. Einstellwerten, und stellt diese über die Klasse in Modulcode oder Formularcode zur Verfügung.
Siehe Logeintrag.

Ich hätte gerne statt der Collection einen Enum verwendet um bei der Implementierung eine Intellisense zu haben. Ist leider nicht möglich diesen dynamisch in der Klasse zu erzeugen?!

Initialisierung: Dim myopt As OptionValueManager: set myopt = new OptionValueManager
Optionstabelle festlegen: myopt.OptionTable = "tblSettings"
Werte auslesen: msgbox myopt.Settings("Feldname")
Werte schreiben: myopt.Settings("Feldname") = neuerWert

Feedback wie immer erwünscht. :o
Gruß Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mi 20. Mai 2015, 18:39

Hallo Andreas!

Nur so als Gedanke:
In meinen Anwendungen speichere ich die Anwendungseinstellungen auch in einer Tabelle ab, allerdings verwende ich je Einstellung einen Datensatz und kein Datenfeld. Damit kann ich Einstellungen ergänzen, ohne den Tabellenentwurf ändern zu müssen.
Zwecks Datentyp könnte man bei Bedarf mehrere Felder mit passenden Datentypen je Datensatz verwenden und z. B. in einem weiteren Feld den Datentyp der Eigenschaft mitspeichern. Damit könnte man über die Klassen den richtigen Datentyp (in Variant eingebettet) liefern.

Deine Variante hat dafür den Vorteil, dass man die Eigenschaften als "fix" betrachten kann und somit eigentlich auch mittels Enum-Auswahl arbeiten könnte.


Bezüglich Enum:
Zur Laufzeit (mde, accde) kann man natürlich kein Enum dynamisch erzeugen - da braucht man es aber eigentlich auch nicht mehr. Man könnte aber während der Entwicklung in einem VBA-Modul ein Enum inkl. Umwandlung in einen String (z.B. über ein Array mit den Eigenschaftsnamen) bei Bedarf einfügen lassen.


Ein paar Kommentare zum Code und Code-Aufbau/Struktur:
Code: Alles auswählen
Public Property Let OptionTable(ByVal NameofTable As String)
    m_OptionTable = NameofTable
    If tableExists Then
        catchOptionValues
    Else
        m_OptionTable = ""
        CancelFlag = True
        MsgBox "Tabelle für Optionen nicht gefunden!"
    End If
End Property

Eine Msgbox halte ich an dieser Stelle für falsch. Ich würde einen Fehler auslösen, damit der Ablauf abgebrochen wird und die aufrufende Prozedur darauf reagieren kann.
Msgboxen haben meiner Meinung nach in wiederverwendbarem Code nicht zu suchen. Die zeigt man höchsten in der obersten Fehlerbehandlungsroutine an, wo man weiß, dass kein anderer Code weiterlaufen wird.

Noch etwas: Bitte Prozedurnamen wie TabeExists groß schreiben, damit das einheitlich bleibt. (VBA/VB6 = Prozedurnamen und Parameternamen groß - egal ob public oder private - weil es leider nicht möglich ist innerhalb eine VB-Projektes unterschiedliche Schreibweisen bei Proezduren bzw. Variablen mit gleichem Namen zu verwenden.)

Bezüglich Benennung von "TabeExists": Wenn ich TabeExists lese, würde ich einen Parameter für die Übergabe eines Tabellennamens erwarten. Da das bei dir nicht der Fall ist, würde ich diese Prozedur eher "OptionTableExits" o. ä. bezeichnen. Auch wenn diese Prozedur nur in der Klasse sichtbar ist, würde ich auf die Lesbarkeit des Codes achten. (Ein "ist ja eh gekapselt" vermeidet nicht, dass der Code in der Klasse selbsterklärend sein sollte. ;-))

Weiters zum Überlegen:
Sind die Prozeduren "tableExists", "isPrimaryKey" usw. überhaupt zentrale Aufgabe der Klasse? - Sollte man dafür nicht eher eine andere dafür spezialisierte Klasse verwenden?
Wenn man die Datenzugriffe auslagert und die per Schnittstelle einzustellen erlaub, könnte ein Entwickler z. B. auch ADODB mit direktem Zugriff auf einen SQL-Server nutzen.

Ich weiß, viele haben am liebsten eine Klasse die alles macht und keine weitere "Hilfe" benötigt. Das führt aus meiner Erfahrung aber dazu, dass man in einer Anwendung an mehreren Stellen ähnlichen Code hat und das macht nicht zu selten ein Code-Verbesserung aufwendiger als notwendig.
... für eine komfortable Auflösung diese Abhängigkeiten habe ich den ImportWizard gestaltet.

LG
Josef
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Mi 20. Mai 2015, 19:02

Hallo,
ja habe die Klasse bereits umgebaut, das mit der Tabelle ist mir auch aufgefallen. Ich mache heute Abend noch ein Update.
OK, das mit dem Err.Raise baue ich noch ein, ebenso eine Tabellenerstellungsroutine.
Wie meinst du das mit dem einfügen bez. des Enums? Zur Entwicklungszeit weiß ich ja noch nicht welche Optionswerte später eingefügt werden.
Hast du mir da ein Beispiel?

Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mi 20. Mai 2015, 19:10

Ich dachte dabei nicht an die Optionswerte sondern an die "Optionsnamen" - also die Feldnamen der Tabelle.

Problem beim Enum: man kann beim VB6-Enum nur Zahlen nutzen. Es besteht keine Möglichkeit gleich die Texte zu verwenden, die man später für den Tabellenzugriff benötigt.
Somit müsste man je Anwendung dafür in einem Modul diese Werte inkl. Array konstruieren - oder man baut in die Klasse einen Code ein, der dieses Enum inkl. Zahlen-zu-Text-Konvertierungsmethode in einem extra Modul auf Basis der Tabelle erstellt.

LG
Josef
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Mi 20. Mai 2015, 19:20

Hallo,
habe die Tabelle umgebaut in die Felder id, strKey, strValue
D.h. die ursprünglichen Feldnamen stecken nun im Feld strKey.
Ich mach mal ein Update der Klasse.

Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mi 20. Mai 2015, 19:33

Ich hoffe, es ist ok, wenn ich ein wenig (hoffentlich konstruktiv) "nörgle". ;-)

Jetzt fehlt mir die Typsicherheit. Ich verwende die in meinen Konfigurationstabellen auch nicht, allerdings stelle ich die Typsicherheit bei mir über die jeweiligen Property-Prozeduren je (Standard-)Einstellung her.

Nur so als Idee:
Was hältst du von einem extra Tabellenfeld in das man dbText-Wert o. ä. abspeichert und bei der Rückgabe des Wertes eine entsprechende Konvertierungsfunktion nutzt?
Oder man verwendet ein String-, Int-, Decimal(18,4) o.ä und Boolean-Feld und greift darauf zu. Die erste Variante ist meiner Meinung nach fexibler und genau so typsicher, da das Abspeichern nach Regeln erfolgen kann.

Ansonsten: wozu ist das ID-Feld gut? Wäre es nicht einfacher, das "Key"-Feld als PK zu verwenden?


Wozu dient CancelFlag?
CancelFlag wird True, wenn die Tabelle nicht vorhanden ist. Wenn es einmal True ist, wird es nie wieder false.
Wenn ich das richtig interpretiere, soll damit verhindert werden, dass "Optionen" abgefragt werden, wenn noch keine Tabelle eingestellt ist.
=> Wozu dann eine extra Variable speicher, bei der man in den einzelnen Methoden darauf achten muss, ob sie nicht True ist? Ich würde einfach beim Datenzugriff auf die Tabelle einen Fehler auslösen, der zeigt, dass die Tabellen nicht passt bzw. nicht eingestellt ist. (Warum soll jedes Mal während der Laufezeit geprüft werden, ob der Entwickler nicht vergessen hat, die Tabelle im Code zu konfigurieren?)

[OT]
Interessehalber:
Findest du die ungarische Notation (str.. usw.) bei Tabellenfeldern praktisch? Ich halte die eher für hinderlich. Wenn man irgendwann einmal den Typ ändern muss (z. B. von byte auf int, von int auf decimal) stimmt entweder das Präfix nicht mehr oder alle anderen Anwendungen die dieses Feld nutzen, müssen überarbeitet werden, was nicht sein müsste, wenn der neue Typ den alten Typ abbilden kann (keine Änderung von int auf varchar o. ä.).
Außerdem wären das für mich immer 3 Zeichen am Anfang die ich tippen muss, um über IntelliSense zur Feldauswahl beim SQL-Managementstudio zu kommen - vor allem muss ich dann eigentlich schon vorher wissen, welchen Datentyp das Feld hat - ich bin ja schon froh, wenn ich den Feldnamen kenne. ;-)

LG
Josef
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Do 21. Mai 2015, 08:22

Hallo Josef,
Das mit dem extrafeld für den Datentyp ist OK. Bislang ging ich davon aus es sei nicht notwendig da eh alles als varchar gespeichert wird.
Das CancelFlag diente zum Abbruch, ist jetzt durch das Err.Raise überflüssig und wird entfernt.
Das mit dem Enum-Erstellen ist jetzt auch klar.
Mit der ungarischen Notation ist es so eine Sache, spielt aber hier keine Rolle da die Felder fix sind und nur noch Datensätze hinzukommen.
Bei der ersten Version wärs vieleicht problematisch geworden.

Was mich jetzt aber viel mehr beschäftigt ist folgendes. Wenn man mal von den Demodaten weg zum Produktiveinsatz kommt, woher weiß ich wie ich den Enum aufzubauen habe wenn noch gar keine Optionswerte in die Tabelle eingefügt wurden? Im Prinzip müsste man einen Dialog starten wo der Anwender seine Optionswerte eingibt und danach der Enum erstellt wird.
Aber dann sind wir weit über das "Klassenziel" hinausgeschossen und eigentlich schon beim AddIn angelangt von der Funktionalität.

Oder wäre es denkbar dass bei jedem initialisieren der Klasse die Tabelle auf neue Einträge geprüft wird und der Enum entsprechend gelöscht und neu erstellt wird?

Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Do 21. Mai 2015, 11:09

Hallo Andreas!

Wir sollten meiner Ansicht nach zw. 2 Arten von "Usern" unterscheiden.
Die User, welche die fertige Anwendung nutzen und die "User", welche die CodeLib-Codemodule nutzen, um damit eine Anwendung zu gestalten.
Für die ersten spielen die Enums keine Rolle, da sie keinen Code schreiben.
Für die "Klassen-Nutzer" ist es meiner Meinung nach zumutbar, dass sie im Direktbereich oder sonst wo eine Routine starten, die die Enum-Code-Teile aktualisiert.

LG
Josef
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Fr 22. Mai 2015, 10:15

Hallo Josef,
bin soweit fertig, aber ich hab da noch ein Problem, die Klasse kann nicht initialisiert werden wenn das "HelperModul" mit dem Enum noch nicht vorhanden ist.
Gibts im Import AddIn eine Möglichkeit Code auszuführen?
Ansonsten würde ich einfach das Modul mit Enum und 1 Dummy-Wert erstellen und mitliefern.

Oder was meinst du?
Gruß Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Sten Schmidt » So 24. Mai 2015, 06:32

Hallo Andreas,

es gibt den Execute-Tag um Code während es Importierens auszuführen, siehe z.B.:
http://source.access-codelib.net/filede ... dSetup.bas
Sten Schmidt
Entwickler
 
Beiträge: 146
Registriert: Do 18. Mär 2010, 22:24
Accessversion: 2016
Access-Erfahrung: Experte

Nächste

Zurück zu Quellcode

cron