CollectionTemplater - Wizard für TCollection-Klassen

[CK_CK]

Hi!
Wenn du den Link noch verbesserst (http:// statt hhttp://), kann man es auch komfortabler runterladen

Viele Grüße,
Chris

[Elvis]

Da du hier einen (fast) vollständigen CodeGen hast will ich mal ein paar Kleinigkeiten loswerden, mit denen ich ihn ganz in mein Herz schließen könnte.

Erstelle eine Art RTL Unit, mit Typen und Funktionen, die die genrierten Units benötigen.
Warum solltenn die das benötigen?
Nun, du könntest dort ein Interface INotifyPropertyChange einführen, das einen Event besitzt, der immer dann gefeuert wird, wenn sich eine Eigenschaft ändert.
Praktisch sowas:

Delphi-Quellcode:

type
  TPropertyChangedHandler = procedure(sender : TObject; aPropertyName : String) of object;

  INotifyPropertyChanged = interface
  ['{37BDED92-FF4C-4B24-B348-194EF999A4CE}']
    function getPropertyChanged : TPropertyChangedHandler;
    property PropertyChanged    : TPropertyChangedHandler read getPropertyChanged;
  end;

Die von dir erstellten CollectionItem-Ableitungen würden dann dieses Interface implementieren und im Setter der Eigenschaften könntest du den Event feuern, wenn sich eine Eigenschaft geändert hat.
Das geiche könnte man auch für die Liste an sich übernehmen. Also ein Interface, was eine Event hat, der einen über Änderungen der Liste informiert (hinzufügen,entfernen,...):

Delphi-Quellcode:

type
  TCollectionChangedHandler = procedure(sender      : TObject;
                                        aIndex      : Integer 
                                        aChangeType : TCollectionNotification) of object;

  INotifyCollectionChanged = interface
  ['{97829CE7-2C68-4151-AC52-9B559D109373}']
    function getCollectionChanged : TCollectionChangedHandler;
    property CollectionChanged    : TCollectionChangedHandler read getCollectionChanged;
  end;

Wozu das Ganze? Nun, jetzt könnte man eine ListView-Ableitung schreiben, die eine solche Collection als Datenquelle bekommen kann und alle Änderungen der Collection sofort darstellen kann (und auch nur die wirklichen Änderungen aktualisieren muss).

Und deshalb als extra Unit, damit sie von mehreren generierten Collection-units benutzt werden kann. (Oder vllt auch angepasst werden könnte)

Außerdem fehlt WideString, was sehr schade ist, da ich AnsiString für die UI für absolut ungeeignet halte. (Wir sind nicht mehr im Jahre 1994 )

Dann sollte das Ganze vielleicht auch von der Kommandozeile aus bedienbar sein, und vielleicht eine kleine, schnieke XML Datei, in der die Einstellungen hinterlegt werden können.
Auf die Art könnte man es in den Build-prozess integrieren.


Ich habe da noch ein paar Ideen, aber ich will dich nicht erschlagen.

[CK_CK]

Sobald die OS-Version kommt, kannst du dich ja ransetzen und es deinen Wünschen anpassen...
-> Aber bitte hier posten, das hört sich nämlich gut an

Chris

[CCRDude]

@CK_CK: Tschschschuldigung da hab ich wohl gestottert

@Elvis: ursprünglich gabs sogar schon eine Hilfsunit, allerdings nur für GetCollectionList Hab das nur in der öffentlichen Version der Einfachkeit halber entfernt gehabt.

ListView: OwnerData hat mir bisher immer gereicht, aber der Vorschlag klingt wirklich nützlich. Bin nur momentan leider zu sehr mit Vista-Services-debuggen beschäftigt, um da gerade Zeit für zu haben. Kannst Du Dir aber gerne in der codetemplate.pas selber einbasteln, wenn es Dir so wichtig ist (und einfach als Patch zur Verfügung stellen, wenn Du magst )

WideString: {$WSOV}, in 0.2.1 ist ja eine Beschreibung der Direktiven auf der Info-Seite. Z.B. für Vergleiche wird automatisch das hier eingefügt:{$WSOV}{_}Result := WideCompareText(<$ITEM>(item1).<$VARNAME>, <$ITEM>(item2).<$VARNAME>); Ansonsten kommen Strings doch nur bei GetDisplayName vor (muss halt für Delphi so sein), sowie für die Ini-Dateien, die ja per IniFiles imho nicht mehr können (und auch den Dateinamen nur normal-string wollen).

Einen Export nach XML (aber bitte nativ, damits auch noch mit FPC unter Linux läuft *g*) hab ich auch noch im Hinterkopf, da wäre UTF8 dann sicherlich angesagt.

Kommandozeile: da die eigentliche Code-Erzeugung in eigener Unit liegt (eine TCollection... mit einer alten Version von sich selbst erzeugt ), ist der Anwendungswrapper drumherum ziemlich egal - das kann sein, was will, natürlich auch ein Kommandozeilenprogramm. Wenn codetemplate.pas erstmal XML unterstützt, ist es ja eine Kleinigkeit, damit dann auch den XML-Lade/Speichercode für das eigentliche Programm ausspucken zu lassen

Nur... das ist ja erstmal nur ein Grundgerüst... in die meisten Collections baut man doch noch das eine oder andere ein (es sei denn, man leitet in einer anderen unit wiederum davon ab), so unbearbeitet im Build-Prozess wär vielleicht ein kleines bißchen übertrieben?

Re Open Source nochmal: ich denke MPL 1.1 dürfte es werden, hab mir ne alte eigene Zusammenfassung davon gerade nochmal durchgelesen, weil mir vom Original immer der Kopf raucht

[Elvis]

Zitat von CCRDude:

Kannst Du Dir aber gerne in der codetemplate.pas selber einbasteln, wenn es Dir so wichtig ist (und einfach als Patch zur Verfügung stellen, wenn Du magst )

Jo, hatte ich ganz übersehen.
Ich habe eben mal ein paar Interfaces und Klassen implementiert, mit denen man seine Datenklassen und Container "Binadable" machen kann.
Als Beispiel habe ich einen Listview, der eine IBindableList als Eigenschaft hat, und er zeigt auch immer schön sofort alle Änderungen der Objekte an.

Ich habe dann noch das template angepasst, so dass Collectionitem INotyPropertychanged implementiert, und die Collection selbst alle nötigen List-spezifischen interfaces.

Ist allerdings nur ein husch-husch-Prototyp und ich muss jetzt nach Paderborn.
Montag oder Dienstag kann ich dir ja mal einen Draft schicken.

Zitat:

Re Open Source nochmal: ich denke MPL 1.1 dürfte es werden, hab mir ne alte eigene Zusammenfassung davon gerade nochmal durchgelesen, weil mir vom Original immer der Kopf raucht

MPL find' ich gut.

[CCRDude]

So, ist jetzt aufgesourct oder wie man das neudeutsch sagt
Eine 0.2.2 steht oben verlinkt, sowohl nur die Binaries als auch die Sourcen, hoffe ich hab nichts vergessen.

Hab auf Anraten jetzt erstmal die LGPL genommen (sollte ja MPL-kompatibel sein), muss mir bei Gelegenheit mal ne ordentliche vergleichende Tabelle aufstellen, die meisten Vergleiche auf Webseiten sind mir entweder zu ausschweifend oder zu kurz. Einfach ne Tabelle mit + oder - zu nem Dutzend Eigenschaften wär doch mal fein Glaub die Readme mit der passenden Info hab ich sowieso noch nicht reingeworfen

XML-Laden ist noch nicht drin, weil XMLLib, welches ich mir mal angesehen hatte, ausdrücklich nur nicht-kommerziell ist, ich aber wie gesagt eine absolut platformübergreifende Lösung möchte (wie gesagt - der Code soll immer auch FreePascal auch unter Linux und MacOSX unterstützen, wo möglich). Sobald das drin ist, dürfte die Kommandozeilenversion für deine Buildchain ein Zehnzeiler sein

[CCRDude]

So, nach einiger Zeit des "Übersehens" hat sich Eset sogar entschuldigt, lag angeblich daran, daß das Programm madExcept verwendet... komisch nur, daß die zweite und dritte Version dann kein Problem mehr gemacht haben, aber egal, wollts nur kurz zur Beruhigung loswerden

[schöni]

Hallo!

Kannst Du bitte auch alle für die Übersetzung nötigen Units mitliefern. Zuerst fehlte FastMM4, jetzt fehlen noch andere Units. Außerdem werden in meinem Delphi 7 nicht alle Komponenteneigenschaften erkannt. Turbo Delphi scheidet zum Übersetzen auch aus, weil die vorausgesetzten Synedit Kompos sich da nicht installieren lassen. Ich besitze D7 Personal mit installierten Synedit Kompos, aber dort werden verschiedene Eigenschaften nicht erkannt. FastMM4 hab ich mir aber inzwischen gesaugt.

Gut finde ich, das die vorcompilierte Version dabei ist, damit ich das Programm dennoch erst mal nutzen kann. Danke für die Arbeit.

schöni

[CCRDude]

FastMM und madExcept sollten eigentlich rein optional sein, leider sind die Direktiven in der .dpr aus dem uses verschwunden, müssen da wieder rein, stimmt (dann lassen sich diese beiden Abhängigkeiten durch einfügen eines Punktes ganz schnell loswerden). Ich lager die Direktiven dafür auch mal in eine CollectionTemplater.inc aus.

Die anderen Abhängigkeiten sind zumindest in der readme.rtf verlinkt. Ich schätze ich könnte die mit reinpacken...

Zu SynEdit: Turbo Delphi muss ich mir auch mal wieder installieren; dummerweise hat das meinen Non-Dev-Rechner das letzte mal zum Absturz gebracht, da bin ich gerade vorsichtig
Ich hab aber gerade mal spontan den Code umgestellt, um diese Komponenten nur noch dynamisch zu erstellen, dann sollte es auch mit Turbo Delphi klappen (da die eh schon für die Template-Tabs dynamisch generiert und Properties gesetzt werden, lag das ja auch nahe).

Muss mal schauen, ob ich das Template in eine wieder vorzeigbare Form bringe (war gerade am experimentieren), dann kann ich das hochladen.

@elvis: was machen Deine Änderungen?

[CCRDude]

So, neue Version (0.2.3), die auch mit Turbo Delphi läuft (und mein Rechner lebt nach dessen Installation sogar noch ). Keine Ahnung wie das mit D7 aussieht, hab da zwar die Personal-Version wiedergefunden, aber bisher nur in ner VM installiert, um da mal ne Portable draus zu machen.

Als weitere Abhängigkeit ist XMLLib hinzugekommen (siehe Elvis' Wunsch, die Konfiguration in XML laden/speichern zu können). Dafür sind FastMM und madExcept über die neue CollectionTemplater.inc ausschaltbar.