Interesse an einem "ClassMaker"?

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