Interesse an einem "ClassMaker"?

[stahli]

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:

!Person
(rw)
  Vorname:String
  Nachname: String
  Alter:Integer
  bezahlt:boolean

!!Personen/Person

!Auto
(rw)
  Hersteller:String
  Knz: String

!!Autos/Auto

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.

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...

[BMI]

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"

http://www.linksandlaw.info/Impressu...e-Angaben.html

mhh, ja, hoffe, Du nimmst mir den Hinweis nicht übel

lg.

[Namenloser]

Das Impressum ist doch da
Der Link befindet sich rechts oben.

[Bernhard Geyer]

Kurze frage: Wieso versuchst du das nicht gleich als Format die XML-Repräsendation von UML-Klassendiagrammen zu verwenden?

[Meflin]

Zitat von Bernhard Geyer:

Kurze frage: Wieso versuchst du das nicht gleich als Format die XML-Repräsendation von UML-Klassendiagrammen zu verwenden?

XML da tippt man sich ja wieder nen Wolf... Der Sinn dieses Tools besteht doch darin (so wie ich das verstehe zumindest), mit wesentlich weniger Tipparbeit zum Ergebnis zu kommen...

[implementation]

Zitat von Meflin:

XML da tippt man sich ja wieder nen Wolf... Der Sinn dieses Tools besteht doch darin (so wie ich das verstehe zumindest), mit wesentlich weniger Tipparbeit zum Ergebnis zu kommen...

Naja, so viel Tipparbeit ist das ja nun auch wieder nicht:

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>

[himitsu]

Kannst dir ja ein Tool schreiben, welches dir diese XML erstellt.

[Meflin]

Zitat von implementation:

Naja, so viel Tipparbeit ist das ja nun auch wieder nicht:

und jetzt vergleiche das nochmal mit der Variante aus dem ersten Post. Locker doppelt so viel...

[mkinzler]

Dafür gibt es aber unzählihe UML-Tools, welche dir diese Datei erzeugen

[stahli]

@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

@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:

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.

So kann ich beliebige Methoden einführen, in denen für jedes Property eine entsprechende Behandlung aufgenommen wird.
In einem Bereich

Delphi-Quellcode:

[PROPERTY]
    property [N]: [T] read Get[N] write Set[N];
[/PROPERTY]

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).
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:

[Units]
xc_.txt=1
xcl_.txt=1
xc.txt=0
xcl.txt=0

[StandardValues]
TGameType=gtNone

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.


Die Komponenten-Property-Definitionen sehen etwa so aus:

Code:

!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

"!" leitet immer eine neue Komponente ein.
">" 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)...