ssFrameWork (StahliSoft - FrameWork)

[Namenloser]

Zitat von bernhard_LA:

wie wäre es mit einem Projekt auf Source forge und mit SVN , dann können wir immer den aktuellen Stand runterladen bzw. auch mal selbst was hinzufügen ?

Da wir 2013 haben vielleicht lieber Github und Git

Ich hab mir eins von den Videos auch angesehen (ebenfalls beschränktes Internet) und es macht zumindest einen guten Eindruck, ich kenne allerdings die LiveBindings nicht und habe daher keinen Vergleich. Testen kann ich es mangels aktuellem Delphi nicht... die Sourcen würden mich eventuell trotzdem interessieren, aber nur aus Neugier

(Oder schon mal drüber nachgedacht, das ganze kommerziell zu entwickeln? Wenn – nach deiner Aussage – nicht mal Embarcadero selbst es hinbekommt, könnte es sich ja vielleicht lohnen...)

[stahli]

Also ich würde das sehr gern kommerziell entwickeln...
(Im Erfolgsfall würde ich dann meinem Avatar auch mal die Mundwinkel hoch ziehen. )

Deshalb möchte ich die Quellen auch nicht open source stellen (davon halte ich grundsätzlich nicht viel, will hier aber keine Diskussion darüber anfachen).
Wenn es Interessenten gibt würde ich das Framework aber sehr gern in einem kleinen Team weiter entwickeln.
Ich selbst kann nur im Feierabend daran arbeiten und bin entsprechend langsam.
Außerdem habe ich auch immer wieder mit Fehlversuchen zu kämpfen, obwohl ja nun die wesentlichen Grundlagen inzwischen gelegt sind.

Als Einzelentwickler bin ich nicht gewöhnt, im Team zu arbeiten. Aber ich würde mich gern mal darauf einlassen.
Wer Interesse hat, einfach mal per pm... (XE2 oder 3 Voraussetzung).


Anbei mal 4 pas-Dateien, die einen kleinen Einblick zeigen.
Am Edit sieht man, was an Ableitung zu einen Standardcontrol notwendig ist. Wenn man ein Control komplett nachbaut kann man natürlich auch komplexere Funktionalitäten regeln.
Die ssProps zeigen, wie die Werte der Objekteigenschaften ermittelt und zugewiesen werden (ist noch in Arbeit).
Den Navigator habe ich neu und einfacher aufgebaut, damit ich die benötigte Funktionalität komplett selbst regeln kann.

[Union]

Also die DB- und Listen-Anbindung solltest Du dringend abstrahieren, speziell im Navigator. Sonst bläst Du den ja irgendwann ins Unendliche auf.

[stahli]

Ja das ist richtig. Zunächst hatte ich nur die ObjektList- und ORM-Anbindung geregelt. Der Zugriff wird über den Manager abstrahiert.
Die IBQuery-Unterstützung kam nachträglich dazu und war eigentlich nicht als Dauerlösung gedacht. Wenn dies aber gewünscht wäre könnte man das noch neu strukturieren. Jetzt wollte ich erst mal die grundsätzliche Machbarkeit prüfen.

ABER: Die FMX-Controls (z.B. der Navigator) zeigen mir, dass es durchaus sehr sinnvoll sein kann, die Controls einfach und übersichtlich aufzubauen, auch wenn dies ggf. einige Zeilen mehr Quelltext erfordert.
So sind auf jeden Fall Anpassungen und Optimierungen leichter vorzunehmen.
Änderungen an den originalen FMX-Controls sind schwierig zu realisieren.
Eine Komponente erstellt man ein mal. Insofern darf es auch etwas mehr Quelltext werden wenn man dadurch die Wartbarkeit verbessert.
In späteren Projekten ist die Funkltionalität dann ja nicht schlechter...

[stahli]

Ich will nun als nächsten Schritt den Komponenteneditor angehen (ein Formular habe ich schon ).
Man wird dort dann die Metadaten für die BL-Objekte (Klassen, Listen und Eigenschaften) definieren, das Speicherziel (Objektlisten, ORM, DataSet) einstellen und die entsprechenden Units erstellen können.
(Falls jemand Erfahrungen damit hat, erzeugte Units direkt in ein Package einzubinden und dies vielleicht sogar zu installieren, wäre er/sie hiermit um Hilfe gebeten.)

PS: Irgendwie ist das lustig, dass ich den Komponenteneditor für das Framework jetzt schon mit dem Framework aufbauen kann (bissl wie "Henne und Ei").

[stahli]

Etwas OT, aber mal zum Thema RTTI:

Ich habe mal Tests bezüglich Geschwindigkeiten durchgeführt. Die RTTI bremst ganz gewaltig.
Wenn man die Funktion sehr häufig nutzt sollte man daher eine Alternative andenken.

Anbei ein kleines FMX-Projekt (Sorry, aber auf VCL lässt sich das ja ggf. auch leicht übertragen.)
Die Formularunit zeigt die verschiedenen Varianten.

Es werden 1Mio Objekte erzeugt und für alle Objkete die Eigenschaft "Value" ausgelesen und neu geschrieben.

Hier die Ergebnisse:

Zitat:

Create OL: 00:00:00.085 - Objektliste
Use OL (Value): 00:00:00.134 - direkte Benutzung der Eigenschaft
Use OL (Func): 00:00:00.239 - Zugriff auf die Eigenschaft über Funktionen
Use OL (Auto): 00:00:00.589 - Zugriff über Funktionen nach automatischer Erkennung
Use OL (RTTI): 00:00:20.688 - Zugriff über RTTI

Create ML: 00:00:00.072 - generische Liste
Use ML (Value): 00:00:00.132 - direkte Benutzung der Eigenschaft
Use ML (Func): 00:00:00.236 - Zugriff auf die Eigenschaft über Funktionen
Use ML (Auto): 00:00:00.583 - Zugriff über Funktionen nach automatischer Erkennung
Use ML (RTTI): 00:00:20.695 - Zugriff über RTTI

Da ich meine BL-Klassen automatisch erzeugen lasse, werde ich den Eigenschaftszugriff über entsprechende Funktionen realisieren.
Im Ergebnis geht das schneller. Mehr Schreibarbeit ist (durch das automatische Erzeugen der Klassen) damit auch nicht verbunden.
Das Framework kapselt den Zugriff und kann selbst die schnelle Version wählen wenn die Klasse dafür eingerichtet ist und andernfalls die RTTI nutzen.

[Stevie]

Zitat von stahli:

Ich habe mal Tests bezüglich Geschwindigkeiten durchgeführt. Die RTTI bremst ganz gewaltig.

Logisch, wenn du für jeden Lese und Schreibzugriff auf die Property die RTTI wieder komplett neu ausliest.