![]() |
Interesse an einem "ClassMaker"?
Für ein eigenes Projekt habe ich mir gerade ein Tool erstellt, das aus einer Definition in einer Textdatei komplette Units erstellt.
Die Textdatei sieht etwa so aus:
Code:
Daraus werden dann komplette Units für Basisklassen (mit einem angehängten Unterstrich, z.B. "TPerson_") erstellt (ähnlich, wie es der XML-Datenbindungsexperte macht). Die Basisklassen haben alle Propertys mit fertigen Getter- und Setter-Methoden. Die Getter und Setter nutzen Methoden ReadString(Propname), WriteString(PropName, Value) und analog für alle in Frage kommenden Typen, die in der ParentClass der Komponenten deklariert sein müssen.
!Person
(rw) Vorname:String Nachname: String Alter:Integer bezahlt:boolean !!Personen/Person !Auto (rw) Hersteller:String Knz: String !!Autos/Auto Von den Basisklassen leite ich dann "richtige" Klassen ab, die ich in meinem Projekt dann verwende, und die wiederum eigene Methoden usw. einführen können (z.B. "TPerson" mit der Funktion "KomletterName"). Neben den einfachen Komponenten (gekennzeichnet mit "!") gibt es auch Listenkomponenten, die mit "!!" deklariert werden. In Klammern können benötigte Units angegeben werden, die dann in der uses-Klausel eingebunden werden. Das Tool erzeugt dann komplette Units und wenn man neue Klassen oder Eigenschaften einführen will, braucht man nur die Struktur in der Textdatei erweitern und diese wieder durch das Tool laufen lassen. In diesem Fall werden die Basisunits (im Beispiel mit "TPerson_") durch neue Units mit den neuen Propertys ersetzt, die "richtigen" Units (im Beispiel mit TPerson) bleiben aber unverändert und können ggf. angepasst werden. Die Schnittstellen auf eine Datenbank (in meinem Fall eine XML-Datei) können so sehr leicht angepasst werden. Ich setze das im Moment für mein aktuelles Projekt ein und erspare mir viel Tipperei dadurch. Besteht da vielleicht grundsätzliches Interesse? Dann könnte ich überlegen, das noch universeller einsetzbar zu machen (grundsätzlich auch für andere Sprachen). Im Grunde werden Mustertexte hinterlegt und Abschnitte wie [ClassName], [Unit], [PRIVAT], [PUBLIC] usw. durch das Tool ersetzt und das ganze zu Units zusammengesetzt. Für meine eigenen Zwecke funktioniert das schon mal sehr gut... :) |
AW: Interesse an einem "ClassMaker"?
Hallo,
verzeih mir den Hinweis... Impressum auf der Homepage fehlt irgendwie. Nicht ,daß ich jetzt darauf rumpochen möchte. aber für jede geschäftsmäßig betriebene Seite muß ein Impressum eingebaut sein. geschäftsmäßig = häufiger aktualisiert, / INhalte angeboten. u.a. könnte ein Ar*** folgenden Satz sogar als Werbung / kommerzielles Interesse auslegen "irgendwann 2 kostenpflichtige Versionen" ![]() mhh, ja, hoffe, Du nimmst mir den Hinweis nicht übel :D lg. |
AW: Interesse an einem "ClassMaker"?
|
AW: Interesse an einem "ClassMaker"?
Kurze frage: Wieso versuchst du das nicht gleich als Format die XML-Repräsendation von UML-Klassendiagrammen zu verwenden?
|
AW: Interesse an einem "ClassMaker"?
Zitat:
|
AW: Interesse an einem "ClassMaker"?
Zitat:
Code:
<?xml version="1.0"?>
<classmaker xmlns:class xmlns:list> <class:Person> <STRING>Vorname</STRING> <STRING>Nachname</STRING> <INTEGER>Alter</INTEGER> <BOOLEAN>bezahlt</BOOLEAN> </class:Person> <list:Personen class="Person"/> <class:Auto> <STRING>Hersteller</STRING> <STRING>Knz</STRING> </class:Auto> <list:Autos class="Auto"/> </classmaker> |
AW: Interesse an einem "ClassMaker"?
Kannst dir ja ein Tool schreiben, welches dir diese XML erstellt. :stupid:
|
AW: Interesse an einem "ClassMaker"?
Zitat:
|
AW: Interesse an einem "ClassMaker"?
Dafür gibt es aber unzählihe UML-Tools, welche dir diese Datei erzeugen :zwinker:
|
AW: Interesse an einem "ClassMaker"?
@BMI: Der Hinweis auf ein Impressum ist immer wichtig (kann ja sonst schnell teuer werden)! Ich habe aber schon eines...
Ein (Neben-)Gewerbe habe ich letztes Jahr angemeldet, aber leider noch keine Einnahmen (außer als Saunameister-Aushilfe). Das Turniersoftwareimperium braucht noch einen Moment - bis dahin versuche ich mich mit dem ClassMaker über Wasser zu halten :wink: @all: Ich habe mich mit den UML-Tools noch nicht näher beschäftigt, glaube aber, dass mein Ansatz einfacher ist und vielleicht auch flexiblere Ergebnisse bringt (sofern man NUR UNITS erstellen will). Ich bin gerade dabei die Anwendung noch etwas flexibler zu gestalten und nun sieht das so aus: Man kann mehrere "Muster-Units" definieren, in denen die variablen Texte [MARKIERT] werden. Die Propertys, die in der Anzahl bei jeder Komponente variieren, werden in beliebigen Sequenzen ersetzt. Bsp:
Delphi-Quellcode:
So kann ich beliebige Methoden einführen, in denen für jedes Property eine entsprechende Behandlung aufgenommen wird.
unit xc[CLASSNAME]_;
interface uses Classes, xc; type Txc[CLASSNAME]_ = class(Txc) private [PROPERTY] function Get[N]: [T]; procedure Set[N](const Value: [T]); [/PROPERTY] protected procedure Clear; override; procedure Make; override; public constructor Create(AOwner: TComponent); override; destructor Destroy; override; [PROPERTY] property [N]: [T] read Get[N] write Set[N]; [/PROPERTY] published end; implementation { Txc[CLASSNAME]_ } constructor Txc[CLASSNAME]_.Create(AOwner: TComponent); begin inherited; NodeName := '[CLASSNAME]'; end; destructor Txc[CLASSNAME]_.Destroy; begin inherited; end; procedure Txc[CLASSNAME]_.Clear; begin inherited; [PROPERTY] [N] := [V]; [/PROPERTY] end; procedure Txc[CLASSNAME]_.Make; begin inherited; [PROPERTY] GetNode('[N]'); [/PROPERTY] end; [PROPERTY] // Txc[CLASSNAME]_.[N] function Txc[CLASSNAME]_.Get[N]: [T]; begin Result := Read[T]('[N]'); end; procedure Txc[CLASSNAME]_.Set[N](const Value: [T]); begin Write[T]('[N]', Value); end; [/PROPERTY] end. In einem Bereich
Delphi-Quellcode:
mit 5 Propertys werden dann eben 5 Zeilen erzeugt, ebenso in den Methoden Clear und Make (die jetzt speziell für meine Komponenten gebraucht werden - für andere Komponenten können natürlich andere Methoden und Bereiche definiert werden).
[PROPERTY]
property [N]: [T] read Get[N] write Set[N]; [/PROPERTY] Innerhalb eines PROPERTY-Abschnittes stehen [N] für PropertyName [T] für PropertyType [V] für einen Standardwert (für eine Initialisierung), der ggf. in einer Ini definiert werden kann. Der letzte Property-Abschnitt erstellt die Getter und Setter, die jeweils wieder beliebige Anweisungen enthalten können (sofern die Struktur für alle Propertys gleich ist). Dazu gehört eine kleine Ini, die folgendes beinhaltet:
Code:
Ich habe also für mich 4 Muster-Units verwendet, von denen die ersten beiden IMMER überschrieben werden. Die anderen beiden werden nur erzeugt, wenn sie noch nicht existieren und leiten "richtige" Komponenten von den vorher erzeugten "Basiskomponenten" ab. Die beiden letzten Units können dann spezielle Methoden einführen, die auch erhalten bleiben, wenn die ersten beiden Units wegen geänderten Propertys neu erzeugt werden.
[Units]
xc_.txt=1 xcl_.txt=1 xc.txt=0 xcl.txt=0 [StandardValues] TGameType=gtNone Die Komponenten-Property-Definitionen sehen etwa so aus:
Code:
"!" leitet immer eine neue Komponente ein.
!Numerator
>xc_.txt >xc.txt Name:String Activate: Boolean !NumeratorList >xcl_.txt >xcl.txt [ITEMSCLASSNAME]=Numerator !Discipline >xc_.txt >xc.txt Name: String NameMirror: String Activate: Boolean GameTypeNumber: Integer GameType: TGameType NumeratorId: String CrossDisciplineId1: String CrossDisciplineId2: String !DisciplineList >xcl_.txt >xcl.txt [ITEMSCLASSNAME]=Discipline !DisciplineGroup >xc_.txt >xc.txt !DisciplineGroupList >xcl_.txt >xcl.txt [ITEMSCLASSNAME]=DisciplineGroup ">" gibt an, mit welchen Units die Komponente erstellt werden soll (gehen beliebig viele). Die einzelnen Komponenten in meinem Beispiel sollen also immer für eine Basisunit und für eine richtige Unit genutzt werden und zwar für 2 verschiedene Komponentenklassen. Ich kann Euch das bei Bedarf gern mal zeigen, wenn es richtig fertig ist (am Wochende, denke ich)... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz