ssFrameWork (StahliSoft - FrameWork)

[stahli]

Die Erfahrungen mit den (Visual) Live Bindings sind sehr durchwachsen.
Auch wenn diese stabil arbeiten würden, wäre das Konzept m.E. nicht wirklich sinnvoll.

Auf der Suche nach einer Alternative habe ich mich mit einem eigenen Lösungsansatz beschäftigt.
Heraus gekommen ist mein "ssFrameWork" (jedenfalls erste Ansätze dafür).


Da das Framework schon recht umfangreich ist, will ich dieses hier zunächst mit zwei kurzen Videos vorstellen:
Demoprojekt: http://youtu.be/MwQooRn67tI
Funktionsweise: http://youtu.be/OpHenJ1EPDE
Das Grundprinzip wird hoffentlich ausreichend verdeutlicht.
(Bitte erwartet keine medialen Kunstwerke, ich möchte hier nur gern die Funktionsweise vorstellen.)


Das DataBinding funktioniert anders als bei den LiveBindings, aber es funktioniert halt.
Der wesentliche Unterschied ist, dass die GUI-Controls sich aktiv ihre Daten von dem Frameworkmanager abrufen und andererseits die GUI-Controls dynamisch vom Framework abhängig von der Datenlage erstellt werden können.


Im Moment habe ich das Framework für FireMonkey aufgebaut (ich hoffe immer noch, dass FireMonkey mit der Zeit verbessert wird und allgemeine Akzeptanz und Verwendung findet) aber es wäre ohne Probleme auch für die VCL realisierbar.
Natürlich sind noch viele Erweiterungen und Optimierungen geplant und erforderlich (insbesondere was die Datenbankfunktionen betrifft), aber ich würde gern schon einmal Eure Einschätzung des Konzeptes erfahren...

Das Grid, die ListBox und den Navigator habe ich nicht von den originalen FMX-Controls abgeleitet, sondern diese komplett neu aufgebaut.
Zum Einen finde ich die originalen FMX-Controls unnötig kompliziert und zum Anderen habe ich so die Möglichkeit, die Controls optimal auf das Framework anzupassen.


Ich bin für jedes Feedback dankbar und hoffe natürlich auf Euer Interesse ...

[Stevie]

Sieht ganz brauchbar aus, ... aber das tun die LiveBindings und Firemonkey in den Embarcadero Präsentationen auch.

Feedback wird also imho erst für dich brauchbar, wenn du mal andere damit rumspielen lässt, die das nicht entwickelt haben (spreche aus eigener Erfahrung).
Dann zeigt sich nämlich wie intuitiv und einsetzbar das ganze ist.

Was mich etwas stört ist, dass das Framework extra Controls braucht. Gerade bei Firemonkey (und in der VCL ab XE2) kann man das wunderbar über den Observer regeln, ohne z.B. Interceptor Klassen zu bauen, wie ich in DSharp gemacht habe.

[Union]

Ja das sieht gut aus. Ich habe dazu aber die eine oder andere Frage:

* Wann kommt die VCL-Version?
* Welche Controls hast Du bereits umgesetzt?
* Wie kann man NICHT von Dir bereits implementierte Controls an das Framework binden?

[Lemmy]

Hi,

da ich ne bescheidene Internetanbindung habe (deshalb ist Video ganz schlecht), würden mich ein paar Sourcen interessieren, insbesondere wie man Controls anbindet (Standardcontrols).

[stahli]

Danke schon mal für das Feedback.

Die Quellen stelle ich ab heute Abend gern zum Testen zur Verfügung.
Das Problem ist, dass ich zum Release 1.0 momentan vielleicht beim Stand von 20% bin.

Probleme gibt es im Moment definitiv beim Überschreiben der Datenbank, da ich damit noch wenig Erfahrungen habe. Testweise nutze ich FB unter IBX, das sollte man aber leicht austauschen können.

Ansonsten will ich noch einen Komponenteneditor erstellen, in dem ich die Struktur der BL-Klassen definieren kann. Der Experte soll dann (abhängig von der gewählten Datenhaltung (ObjektListen, ORM, DataSet)) die Klassen für die Datenverwaltung erstellen. Diese Klassen sollen dann durch den Experten jederzeit aktualisiert werden können.
Der Programmierer kann von den automatisch zu generierenden Datenklassen BL-Klassen ableiten, die die Geschäftslogik definieren.
Soweit meine Vorstellungen dazu. Aber das muss halt noch realisiert werden.

Wer dennoch Interesse am aktuellen Stand hat, einfach mal per pm schreiben...


Derzeit habe ich nur das Edit und die Checkbox angepasst (Grid, Listbox und Navigator neu zu entwickeln war mir dann wichtiger). Die anderen Controls sollten aber auch leicht anpassbar sein.
Ebenso die VCL-Controls. Wenn da Nachfrage besteht kann ich das mal mit angehen (ab Delphi 2010 sollte das machbar sein).


Dass man spezielle Controls nutzen muss (ähnlich den DBControls unter VCL) halte ich nicht unbedingt für nachteilig. Ich hatte auch schon Versuche erfolgreich durchgeführt, einem "normalen" Control (z.B. existierenden Edit) einfach nachträglich einen Controller anzuhängen und das Binding dann so zu realisieren (mit Hilfe eines SubClassing - oder wie heißt das wenn eine Klasse dynamisch zur Laufzeit Compiletime überschrieben wird?).
Ich fand es dann aber besser und übersichtlicher, spezialisierte Controls einzuführen. Aber da kann man ja nochmal drüber nachdenken, wenn gewünscht.
(Aber die FMX-Controls sind ja letztlich auch schon spezialisierte Controls, um mit dem LiveBinding umzugehen. Irgendwie müssen die Controls ja ihr Funktionalität auf das Framwork anpassen.)


Zumindest freut mich sehr, dass Euch der Grundgedanke offenbar gefällt.

[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 ?

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