Auch wenn LEO einem das einredet: ERP ist funktional etwas anderes als WWS, und die Übersetzung ist mindestens schädlich. ERP ist was für Industriebetriebe, WWS für Händler. Letzteres ist erheblich weniger komplex.
Just my 2 Cents.

Das Problem liegt nicht bei mir, sondern bei dem allgemeinen denglisch in Deutschland.
Ich habe versucht, die Software-Vorstellung so allgemein wie möglich zu halten, so dass die verschiedenen Gruppen hier verstehen können, was gemeint ist. Nicht jeder versteht ERP oder kann sich unter "Enterprise Resource Planning" etwas vorstellen, aber unter Warenwirtschaft.

Und genau deswegen habe ich auch am Anfang darauf hingewiesen, dass man ERP zu gut deutsch als Warenwirtschaft-System bezeichnet, denn genau das machen die denglisch-Spezialisten in den Firmen, wenn sie ihre Reden halten

Dass meine Komponenten für beides gehen, dürfte auch Dir aufgefallen sein. Und von daher ist die Aussage "die allgemeine Begeisterung etwas dämpfen" etwas fehlerhaft, da Deine Kritik sich weder auf Funktionalität, Idee, Nutzen noch Originalität bezieht, sondern eben nur auf den "Fehler" im ersten Satz in einem Artikel, welcher versucht, jedem von der ersten bis zur letzten Zeile verständlich machen zu wollen, um was es geht.

Dann bitte ich um Nachsicht dafür, dass ich Deine Aussage "zu gut Deutsch" mit "gutem Deutsch" verwechselt habe. Ich halte es weiterhin für schädlich, die beiden Begriffe zu verwechseln (ist aber mein Privatvergnügen).

Edit: das mit der Begeisterung war in der Hinsicht gemeint, dass manche vielleicht ERP-Funktionalität in Deinen Komponenten erwarten ...

ERP-Funktionalität ? von einem Framework ? Das wäre ja so, als würde man von einem TForm erwarten, schon 3D-animierte Charaktere darzustellen in wahlweise OpenGL oder DirectX...
Denn wie der Name "Framework" ja schon sagt, biete ich mit den Komponenten Rahmenbedingungen für ein modulares System (ob nun ERP oder WaWi), welches weit über herkömmliche modulare Plugin-Systeme hinausgeht, da diese Komponenten nicht nur irgendwo 'nen neuen Button hinsetzen oder ein Menü erweitern, sondern den Code von Funktionen eines solchen Systems auf einer frei vom Programmierer gewählten Ebene manipulieren können, ihn erweitern, verringern, ersetzen. Und dies, ohne ausgelieferte Module neu übersetzen und beim Käufer austauschen zu müssen.
Desweiteren bieten die Komponenten Nachrichten-Systeme für Fenster, welche auf Module verteilt liegen, sich nicht kennen und vllt. einfach nur auf einer gemeinsamen Basis arbeiten, und lässt diese miteinander kommunizieren. Denn oftmals ist dies auch das grosse Problem der Programmierer von solchen Systemen, worauf man sich entscheidet, alles in eine Anwendung zu packen und dies als 8MB-EXE auszuliefern.
Dazu werden Fensterklassen als Beispiel dazugelegt für verschiedene Anwendungsbereiche und in ihnen gezeigt, auf was meine Komponenten wert legen etc.

Alles in allem ist es ein Framework und keine ERP-Anwendung, die Komponenten sind dazu da, dem Programmierer später die Arbeit zu vereinfachen, da er sich nicht mehr mit der Basis-Programmierung rumschlagen muss, sondern seine Logik des Systems auf meinem Framework aufbaut.

Aber wahrscheinlich wirst Du jetzt etwas am Wort Framework auszusetzen haben und dass man es nicht in diesem oder jenem Kontext benutzen kann.. *grummel*

Einfache Frage: Du hast aber jetzt Warenwirtschaftskomponenten, und keine ERP-Komponenten, oder? Oder kann man mit deinen Komponenten auch Resourcen planen? Minimum Workflow und den ganzen Schmunz?


Sei mal nich so grummelig, ob das nun WaWi- oder ERP-Kompos sind... Ist doch wurscht, wie sie heißen. Wichtig ist, das die was taugen, oder? Dann kannst Du sie auch Horstel nennen. Und so wie das aussieht, sieht das doch nach was aus, oder?

Nicht grummeln, anscheinend war ich etwas zu pedantisch, was die Begriffe angeht - muss ich mir in diesem Forum wohl abgewöhnen. Aber: haben die Komponenten keine Funktionalität, verstehe ich das richtig?

Also wir der Name schon sagt : Es sind ERP-Framework Components !

Ich frage mich, was an dem Wort Framework so schwer zu verstehen ist, besonders nach dem Lesen des Textes...

Was können meinen Komponenten nicht : Kaffee kochen, obwohl unerlässlich in jeder Firma, die ERP oder WaWi einsetzt und wo diese Programme durch Kollegen/Kolleginnen (nicht das jetzt noch ein Grüner kommt und meckert, ich würde die weibliche Belegschaft in Firmen nicht ausreichned würdigen... ) bedienen lässt...

Habt ihr denn den Text überhaupt gelesen ? Die Frage geht im Besonderen an Bex, der offensichtlich sehr penibel ist, aber anstatt lieber zu lesen, was die Komponenten können, erstmal die Frage stellt, ob die Komponenten "denn Funktionalität haben"...

ok, ich gebs auf, du hast mich erwischt, ich habe nur einfach von TComponent abgeleitet, der Klasse somit einen neuen Namen verpasst und versuch nun, diese zu verkaufen.. mist, das klappt jetzt wohl nicht. Du kannst jetzt mit dem Lesen hier aufhören, es geht wieder um Funktionalität...

@alle anderen, die es geschafft haben, den Text zu lesen : sorry, das musste jetzt raus.
Also ich biete nicht ERP-Funktionalität selbst an, sondern die Rahmenbedingungen, um ein modulares ERP-System mit viel weniger Aufwand als normal zu schreiben. Ich kann keinem Programmierer die Arbeit abnehmen, seine Logik zu schreiben und es ist auch nicht der Sinn dieser Komponenten. Ich habe versucht, einen Misstand zu beheben, den viele ERP-Systeme gemein haben. Dazu gehört die fehlende Modularität und Austauschbarkeit von Code, die Möglichkeit, Systeme durch "plugins" flexible zu erweitern ohne auf die Schwächen vorhandener Plugin-Systeme Rücksicht nehmen zu müssen. Zudem versuchte ich, eine Basis zwischen all den Programmen zu finden und etwas cleveres zu einzelnen Bereichen beizutragen. Da man selbst selbst bei vorhandener Kenntnis der Technik meines Systems (wie gesagt, auch ich koche nur mit Wasser) Monate braucht, um Vergleichbares nachzubilden, bietet sich hier einfach ein Markt, der bisher nicht erschlossen ist (zumindest scheint es mir so, ich habe nichts Vergleichbares gefunden).

Natürlich kann man die Komponenten auch für andere Systeme nutzen, wie WinAmp , ICQ oder Spiele, und ich hätte sie demzufolge auch Super-Hyper-Plugin-System nennen können, aber erstens ist es nicht nur das, es bietet viel mehr (näheres in den Eingangs-Posts von mir) und zweitens schreibe ich modulare ERP-Systeme seit Jahren und würde allein deswegen einfach mal in den Raum stellen, dass ich da nicht unbedarft bin und weiss ungefähr, was benötigt wird und habe meine Komponenten aus der Not des Nicht-Vorhandenseins solchiger geschrieben.

Ich habe nie behauptet, ERP-Funktionalität selbst anzubieten (jeder, der den Post wirklich gelesen hat, weiss das), und den Anspruch will ich mit den Komponenten auch nicht stellen, weder jetzt noch in Zukunft. Um was es mir geht und immer ging, sind die Funktionen, wie man ein modulares und einfach zu erweiterndes System aufbaut, wie man Kommunikation in einem System regelt, wo niemand niemanden kennt etc.

Tut mir wirklich leid, dass ich Dir "zu penibel" bin - aber wenn ich im Thread-Titel ERP lese und das noch weiter dauernd im Text vorkommt, dann fühle ich mich schon veräppelt, wenn es nichts mit ERP zu tun hat, was da angeboten wird. Du verkaufst ja auch keine Bleistifte unter dem Namen, nur weil man damit auch planen kann. Ist für mich Etikettenschwindel.

Könntet Ihr das bitte per PN klären? Ich denke, aller spätestens nach Helges letztem Posting ist klar, worum es geht, damit hat das hier nix mehr zu suchen.

HelgeLange hat folgendes geschrieben:

Wenn man in Hooks neuen Code einfügt, hat man eine Option : markieren Delphi-Quelltext     1:      THookInsertDirection = (hidWhoCares, hidBefore, hidAfter, hidFirst, hidLast);

Hast du irgendwo auch eine Replace-Funktion? Also dass man eine Prozedur einfach so ersetzten kann? z.B. kann ja sein, dass einem eine Stelle überhaupt nicht gefällt, von der Funktionsweise her

z.B. gefällt einem das hier nicht:

und will statt dessen


Kann man also vorgefertigte auch erstezten, oder sind diese dann fest drin?

Aso, noch als Hinweis. Wikipedia hat ERP so übersetzt: "Planung [des Einsatzes/der Verwendung] der Unternehmensressourcen"

@Heiko :

Wie ich erwähnt hatte, ist das ganze System skalierbar, d.h. der Programmierer entscheidet, an welchen Stellen er statt eines Aufrufs an eine ihm derzeit bekannte Funktion eine virtuelle Funktion setzt.

Virtuell deswegen, weil es die Funktion erstmal nicht gibt im System. Das ist eines der Grundprinzipien eines Keiner-kennt-keinen-Systems. Oder zumindest ist es meiner Definition nach so. Als Programmierer des Systems mit den "ERP Framework Components" weisst Du nur, dass es eine Funktion gibt, die macht, was du an dieser Stelle im Programm brauchst, aber Du weisst nicht, wo diese sich befindet oder wie sie es macht. Beides ist Dir auch egal, weil Du in diesem Moment eine Anforderung hast, diese mit dem Aufruf des Hooks artikulierst und der HookManager sich darum kümmert, dass die in diesem Augenblick gültige Funktion diese Aufforderung zugetragen bekommt.

Willst Du nun das Passwort, wie in Deinem Beispiel, überprüfen, kannst Du sogar viel weiter gehen, als nur die Funktion zu ersetzen. Du kannst sie universell machen. Du schreibst Dir für alle im System benutzten Programme mit Passwort (eine ERP-Landschaft kann ja aus n-verschiedenen Programmen verschiedener Hersteller bestehen, wobei Schnittstellen diese mehr oder minder kommunizieren lassen) eine entsprechende Funktion, die das Passwort prüfen kann. Soweit ist das ja auch im Programm ohne meine Komponenten gleich.
Hast Du nun sagen wir 5 verschiedene Programme, die Dir über ihre Schnittstelle Login/Passwort zur Verfügung stellen, allerdings die Passwörter auf verschiedene Art und Weise geprüft werden müssen, schreibst Du einfach die 5 Funktionen für die verschiedenen Systeme, hängst alle an einen Hook und wertest das Ergebnis aus, denn war das Passwort richtig, wird Dir das eine der Funktionen im Event melden und Du kannst weitergehen in Deinem Programm. Meldet keine der Routinen Erfolg, war das Passwort falsch oder mit einer 6. Methode encrypted.
Wo wir bei dem zweiten grossen Vorteil sind. Taucht nämlich die 6. Methode auf, müsstest Du an Deinen Code wieder ran, diese Methode integrieren und dein Programm mit allen 6 System-Schnittstellen und ihren Passwörtern testen und dann wieder ausliefern. Unter Umständen kann es Probleme bei denen Deiner Kunden geben, die die 6. Methode garnicht brauchen etc...
Mit den "ERP Framework Components" schreibst Du nur die Methode in ein gesondertes Modul für die Kunden, die das brauchen, meldest dort die Funktion unter dem gleichen Hook wie die anderen an und fertig. Du brauchst weder dem Kunden ein komplettes Set neuer Module unterschieben noch ihm die EXE neu übersetzen, weil sich der Code geändert hat. Und wie gesagt, Du kannst es an denjenigen ausliefern, der es wirklich braucht. Das verringert zusätzlich die Gefahr sogenannter Side-Effects bei Systemen, für die das update nicht gedacht war (weil ihnen das 6. Programm fehlt).

Und natürlich kann man einzelne Funktionen eines Hooks löschen oder umleiten. Gefällt einem Kunden ein Dialog nicht mehr und dein Designer (oder eben Du) hat sich rangesetzt, einen neuen zu erstellen nach den Wúnschen des Kunden, musst Du danach nicht ihm das komplette Modul austauschen mit seinen 50 Funktionen, sondern ein neues Modul machen mit dem neuen Dialog und leitest die Funktion um, so dass statt die Funktion in Modul A aufzurufen, diese jetzt in Modul F zu finden ist.

@Bex: Leider machst Du immer noch den Fehler, "ERP Components" und "ERP Framework Components" zu verwechseln. Entweder willst Du das Wort Framework nicht sehen, oder aber du kannst den Unterschied zwischen einem fertigen System und einem Framework für ein System nicht verstehen.

Was ist ein Framework ?

Das dt. Wikipedia sagt dazu :

Zitat:

Framework (engl. für Rahmenstruktur, Fachwerk) ist ein Begriff aus der Softwaretechnik und wird insbesondere im Rahmen der objektorientierten Softwareentwicklung sowie bei komponentenbasierten Entwicklungsansätzen verwendet. Wörtlich übersetzt bedeutet Framework (Programm-)Gerüst, Rahmen oder Skelett. Darin wird ausgedrückt, dass ein Framework in der Regel eine Anwendungsarchitektur vorgibt. Dabei findet eine Umkehrung der Kontrolle statt: Der Programmierer registriert konkrete Implementierungen, die dann durch das Framework gesteuert und benutzt werden, statt – wie bei einer Klassenbibliothek – lediglich Klassen und Funktionen zu benutzen. ...

"ERP Framework Components" in einem modularen System

Mein Komponentenpack stellt somit Komponenten für ein Framework zur Verfügung und übernehmen innerhalb des Frameworks spezifische Aufgaben. Aber ausserdem geben sie auch den Rahmen vor : es muss eine modulare Anwendung sein. Warum ist das so wichtig ? Weil es keinen Sinn macht, meine Komponenten in einer 8MB-EXE unterzubringen, da diese sowieso neu kompiliert werden muss, wenn etwas geändert wird.
Sehr wohl kann die EXE allerdings die Basis eines modularen Systems sein, aber selbst keine Module zu besitzen im Ursprungs-Zustand und erst zusätzliche Funktionalität aufweisen kann, wenn Module hinzugefügt werden. Wie das modulare System kommuniziert gebe ich vor, wenn meine Komponenten eingesetzt werden (sofern der Programmierer alle benutzt, das hängt von ihm ab, allerdings manche Komponenten benötigen andere im System, um lauffähig zu sein, das bedingt die Architektur).
Dabei sind die Komponenten selbst mehr oder minder konfigurierbar in ihrer Arbeitsweise, einmal zur Designtime und auch zur Runtime. Das heisst, es gibt zwar Vorgaben, wie manche Prozesse laufen müssen (Deklaration von Funktionen für den HookManager, um als solche benutzt werden können zum Bsp.), aber das ist offen genug, um akzeptiert zu werden und vergleichbares wird ja innerhalb von ziemlich jeder Hochsprache benutzt.

Warum beinhaltet der Name die 3 Wörter "ERP", "Framework" und "Components" in dieser Reihenfolge ?

ERP, weil ich denke, in ERP (und ERP-ähnlichen) Systemen sind sie am besten aufgehoben, da genau dort diese modulare Funktionalität benötigt wird und ich dort das Kunden-Potential sehe. Ich hätte sie auch Hundefutter nennen können, doch eine Suche eines potentiellen Kunden würde meine Komponenten dann nicht als Ergebnis bringen. Dafür würde ich viele Anfragen von Hundebeitzern bekommen, wie ich das mit den Modulen bei Hunden meine und ob Hunde auch mit allen Modulen gleichzeitig spielen können. ;)

Framework, weil sie nicht die ERP-Funktionalität selbst abbilden, sondern für das Grundgerüst eines Programms gedacht sind, welches ERP-Funktionalität implementiert. Das hat den Vorteil, dass ich dem potentiellen Kunden nicht in die Lage bringe, sich meinem Denkschema in seinem ERP-System anzupassen. Dass ich ihn in mein modulares Denkschema presse ist aber ein eher gewollter Effekt, der uns beiden zugute kommt. Und der auch vom Käufer so gewollt ist. Niemand kauft sich Hundefutter und fragt sich danach, warum der Fernsehempfang auf der Hundefutter-Tüte schlecht ist.

Components heisst es aus 2 Gründen.
1.) Ich biete kein komplettes Framework an, da es eventuell wiederum den Anwender der Komponenten einschränken würde. Es muss meiner Meinung nach genug Platz für eigene Ideen da sein. Und so wie ich das sehe für meine "Babies", mache ich dem Programmierer sogar mehr Platz, als er mit den jetzt erhältlichen Plugin-Systemen hätte.
2.) Es ist Mehrzahl, denn in dem Pack gibt es mehr als eine Komponente, die mehr als einen Bereich abdecken. Dazu gehört das Hook-System der dynamischen Funktionen selbst, sowie Kommunikations-Komponenten, Daten-Zugriffs-Komponenten und und und (Siehe Beschreibung in den Eingangs-Posts).

Insgesamt könnte man es ins Deutsche mit folgenden Worten übertragen : Komponenten für ein Basis-System von ERP-Software. Ok, da sind immer noch viele englische Wörter drin, nur benutzen wir die ja eh im Deutschen genau so.

Abschliessende Betrachtung

Aus den oben angeführten Argumenten erkennt man, dass es kein Etiketten-Schwindel ist, meine Komponenten als "ERP Framework Components" zu bezeichen, da es Komponenten sind, welche für ein Framework eines ERP-Systems gedacht waren (immer noch sind !) und der Name nur als komplette Einheit zu betrachten ist. Sie erheben weder durch Namen noch durch Inhalt den Anspruch, ERP-spezifische Aufgaben zu erfüllen, sondern sie können innerhalb eines Frameworks für ein ERP-System Aufgaben übernehmen und somit dem Programmierer eines solchen Systems die Arbeit ungemein erleichtern.
Jeder Hersteller von ERP-Systemen entwirft mehr oder minder sein eigenes Framework dazu. Wie ausgeklügelt dies ist, sei in den Raum gestellt, aber ich kann mit meiner Berufserfahrung im Allgemeinen und mit meiner spezifischen Erfahrung in der Programmierung modularer Systeme mit Bestimmtheit sagen, dass meine Komponenten die Arbeit definitiv leichter und universeller machen, dazu dem Hersteller von ERP-Lösungen eine Menge Geld sparen, denn es dauert Monate, Vergleichbares zu meinen Komponenten zu programmieren, selbst wenn man die Idee selbst hat. Gerade auch weil so ein System wächst. Die Komponenten meines ERP Framework-Packs sind auch nicht mit einem mal entstanden und seitdem in dieser Fassung, sondern sie unterliefen einem Entwicklungsprozess.

Ich denke, die Diskussion über Deine Namensgebung führt nicht wirklich weiter; jeder Kunde muss selbst entscheiden, ob er sich bei Dir wiederfindet oder nicht. Für mich sieht Dein Ansatz nach einem generischen Framework aus (Schade um die Einschränkung auf ERP) ...

Was das Framework betrifft: die Idee finde ich nach wie vor gut; mir hat sie schon in den 90-ern gefallen, als IBM dasselbe vorhatte, was bei Dir die Grundidee hinter dem ganzen zu sein scheint (Stichwort SanFrancisco). Die haben das ganze leider nicht mehr weiterentwickelt. Ich drücke Dir die Daumen, dass Du die nötige Entwicklerpower zusammenbekommst, um es besser zu machen

Leider kenne ich die Idee von IBM nicht, von daher kann ich nicht sagen, was die vorhatten oder so.
Meine Idee funktioniert seit einigen Jahren sehr gut, ich brauche da keine weiteren Entwickler, um dies fertig zu stellen, denn alles, was ich im Moment mache, ist polieren und einige Routinen, die ich drin haben will vor dem Release, um es den Leuten einfacher zu machen, mit meinem System zu arbeiten.

Dass das System sehr generisch sein kann, ist mir auch klar und habe ich ja auch im Beitrag so gesagt. Nur sehe ich das Kunden-Potential hauptsächlich in der ERP-Entwickler-Ecke, aus verschiedenen Gründen, denn diese Leute bauen Anwendungen, welche

1.) Modularität und Austauschbarkeit haben sollten
2.) gross genug sind, um das potential wirklich zu nutzen
3.) einen Datenaustausch und eine Erweiterung der Datenverarbeitung benötigen

Nichts desto trotz habe ich ja einen Mini-Treiber gebaut für den HookManager, der mit der Registry arbeitet und dadurch auch für viel kleinere Programme, die ohne Datenbank auskommen (müssen), genutzt werden kann.

Aber durch die Namensgebung mache ich ja hauptsächlich die Gruppe auf mich aufmerksam, welche ich mit dem Produkt vorrangig ansprechen will. Wenn mich noch andere finden und zuschlagen... ich kann damit leben Vielleicht wird es die Komponenten für die dynamischen Funktionen auch in Zukunft als Mini-Package geben, nur mit den Registry-Treiber daherkommen und ohne die Lizenz, diesen mit mehr zu nutzen als diesem Treiber, wobei das "grosse" Paket andere Treiber (für andere Datenbanken), die auch vom Käufer entwickelt werden können, nutzen können. Das Framework dafür ist geschaffen durch eine Objekt-Orientierte Programmierung, so dass nur die Datenbank-spezifischen Funktionen, welche in einem DB-Objekt gekapselt sind, auf eine andere DB umgeschrieben werden müssten.

Alles in allem kann es ein Paket sein, was viel mehr Leute anspricht, als nur ERP-Software-Entwickler, nur besteht dort eben das Problem, dass man den Namen hätte allgemein halten müssen und dann wird das Interesse von den Leuten, für die ich es gebaut habe, nicht geweckt

Grüsse aus Caracas,

War ein Java-Framework. Ganz guter Überblick: www.sts.tu-harburg.d...-OS-SanFrancisco.pdf

Auf dem Framework basierend sollte beispielsweise im Fiscus-Projekt die einheitliche Software für alle deutschen Finanzämter implementiert werden. Zum Thema SF sind zwischen 1997 und 2001 diverse Diplom- und Doktorarbeiten geschrieben worden - ich kann Dir gerne ein paar Titel heraussuchen, wenn Interesse bestehen sollte.

Wie schon gesagt, SanFrancisco wurde von IBM beerdigt (ich glaube endgültig 2002). Das Hauptproblem war, wenn ich mich recht erinnere, dass nicht genügend andere Softwareentwickler auf den Zug aufgesprungen sind.

Das spielt ja für mich dann eher keine Rolle, da mein System sich damit beschäftigt, dies innerhalb eines Programmes zu bewerkstelligen. Ich will nicht den Anspruch erheben, ein Framework zu erschaffen, welches von sich aus n-verschiedene Programme unter einen Hut bringt oder eine gemeinsame Entwicklungs-Basis für verschiedene Programme zu schaffen, die dann über diese Basis kommunizieren sollen.

Wie ich im Beitrag die ganze Zeit klar gemacht habe, besteht das Framework aus mehreren Komponenten, wobei eine davon lapidar (und abwertend) als Plugin-System bezeichnet werden kann. Denn was heutzutage als Plugin-System bezeichnet wird und Anwendung findet, wird meine Meinung nach dem namen gerecht, aber von der Funktionalität und den Möglichkeiten meines Systems weit übertroffen. Alles weitere dazu eben in den vorherigen Posts...

Btw.. die Demo verzögert sich etwas, denn hier gab es im Kabel-System vorm Haus eine Explosion und scheinbar hat es meinen Arbeits-Computer mitgerissen. Ich bin gerade dabei, ihn zu fixen.

Hi, mal wieder ein kleines update... weiss ja nicht, ob die interessierten Leser auch mein DevBlog lesen

Zur Zeit baue ich grad den Router um, der kriegt 4 neue Komponenten spendiert und verliert dabei 'ne Menge Code. Warum das ganze ? Es wird der komfort erheblich erhöht, es kommen ein paar neue Funktionen dazu und es wird die chance auf ein kleineres, billigeres non-source-Paket erhöhen.

Wer den Thread bisher gelesen hat, wird wissen, dass der Router aus mehreren Teilen besteht. Da diese alle im ganzen Programm nur 1x benötigt wurden/werden, sah ich bisher noch keine Veranlassung, diese als Komponenten zu schreiben, sie waren Teils im DatenModul, teils in Objekten vergraben.
Nun habe ich mir einige Teile rausgesucht und schreibe diese grad als non-visual-Komponents um.

- HookManager
- DB Zugriff
- SecurityLayer

HookManager & SecurityLayer werden dabei mit der DB Komponente verknüpft und können ihre Daten von dieser beziehen. Die DB-Zugriffs-Komponente ist wieder als Custom-Variante mit vielen abstracten und virtuellen Methoden als Basis vorhanden, diese ist keine Komponente in der Komponenten-Palette, dafür gibt es eine integrierte Registry-Access-Komponente sowie in jeweils extra Packages für verschiedene Datenbanken Ableitungen dieser Basis-Komponente.

Den SecurityLayer kann/muss man mit der HookManager-Komponente verknüpfen. Ist sie nicht verknüpft, werden keine Sicherheits-Profile geladen und gut. Ist sie da, hat man 2 Möglichkeiten :

1.) Vorgegebene Tabellen zum Laden der Rechte benutzen, wobei die Tabellen-Beschreibungen für jede Datenbankart als sql-Script mitgegeben werden
2.) Benutzerdefiniert laden, wobei eigentlich ein Event gefeuert wird, der Nutzer drauf reagieren kann, die Daten laden, wo er möchte und dann per API hinzufügen.

Was meint ihr : Ist es generell problematisch, Tabellen vorzugeben für ein Produkt, was zum Teil auf Datenbank basiert ? Irgendwo muss ich meinen Kram ja auch speichern, oder ? gerade wenn es um dynamische Sachen geht, die mit jedem installierten Modul sich ändern. Die andere Möglichkeit wäre eben, es vollkommen Laufzeit-abhängig machen, das heisst, alle Daten werden von den Modulen beim Start angefordert, einsortiert, verworfen etc., also alles, was ich sonst beim Install einmal mache und gut...

Würde mich über Antworten freuen

hm.. es gab zwar in den letzten 2-3 Tagen ca. 400 Zugriffe, aber keine Antwort.

Also, der augenblickliche Stand ist folgender :

THookManager : 90% done
die fehlenden 10% bin ich mir nicht sicher, ob ich sie vor dem Release einbaue, denn sie sind eine reine Neuerung. Beim Umbauen habe ich halt festgestellt, dass wenn ich eh schon am Code so derb rumbaue, dann kann ich es auch gleich richtig machen. Habe dazu die Speicherverwaltung für die DFT (DynamicFunctionTable) umgeschrieben und kann rein technisch das Erstellen der DFT beim Programmstart machen, muss nur den entsprechenden Code für re-init etc implementieren. Dazu gibt es eine Boolean-property SaveDFT, welche zur Designzeit bestimmt, ob ein angeschlossenes DBObject zum speichern in eine DB genutzt werden soll. Steht diese auf False, wird beim Start die DFT aus den registrierten Modulen frisch gebaut (langsamer, logischerweise... allerings nur beim Start, danach ist alles gleich).



die Properties :
AutoLoad : die Komponente lädt Module und DFT automatisch, da gibt es noch einen kleinen Timing-Bug, wenn die Komponente eher geladen wurde als die Datenbank und ich will mich nicht an deren OnConnect hängen... überlege mir noch was dazu
BaseDB : die verbundene BaseDB Komponente (siehe weiter unten)
FunctionCount : zeigt an, wieviele Dynamische Funktionen geladen sind
ModuleCount : zeigt an, wieviele Module geladen sind
ModuleLoadMethod : mlmDataBase = es wird von Datenbank die Liste der Module genommen, das ist gut, wenn ein Netzwerk-LW alle module beinhaltet, aber je nach Workstation nur eine Selektion geladen wird. Im Gegensatz dazu die Einstellung mlmDirectory, wo alle Module aus einer Directory geladen werden, geprüft, ob es ein Modul für das ERP-System ist und dieses dann entsprechend geladen. Funktioniert gut, wenn man eine IT-Umgebung hat, wo jeder Rechner sein eigenes Module-Verzeichnis hat oder wo alle Clients alle Module laden müssen.
ModulePath : wird für 2 Sachen genommen. Einmal für die Einstellung ModuleLoadMethod und auch für das Laden der Module selbst, da diese ohne Pfad in die DB geschrieben werden.
Name : Kopmponentenname natürlich
SaveDFT : gibt an, ob die BaseDB-Komponente zum speichern benutzt werden soll
SecurityLayer : gibt die SecurityLayer-Komponente an. Ist sie nicht angegeben, werden alle Dynamischen Funktionen geladen.

TERPCustomBaseDB & TFIBBaseDB :

Während TERPCustomBaseDB eigentlich nur vorgibt, was da sein muss und dadurch eine gemeinsame Basis für alle BaseDB-Ableitungen bildet, ist TFIBBaseDB die eigentlich Implementierung. Einige Funktionen kann man natürlich schon in der Base-Komponente machen. Aber das sieht man ja dann im source. Auch hier das OI-Bild dazu :



Gehen wir auch hier mal durch die Properties:
ComputerName : Name der Workstation
Connected : True setzt (oder versucht es eben) die DB-Verbindung auf Active/Connected.. je nach dahinterliegender DB
ConnectionData : Zeigt Conenction-Data an, ID des Users (aus DB), die SessionID und wann die Session gestartet wurde.
Database : hier setzt man die zu benutzende Datenbank-Komponente, in diesem Fall gehen nur die von FIBPlus, es wird aber noch weitere anleitungen geben, welche andere DB-Komponenten einbinden
DataBaseName : Connections-String für die Datenbank, jeder Interbase/Firebird-Nutzer kennt den
HookLoadOptions : Je nachdem, was in StoreTableName eingestellt ist, wird entweder der Name der Workstation (aus CompuerName), der Name des Users oder eben nichts als Prefix genommen. Dadurch ist es möglich, das Laden von Modulen und Funktionen abhängig von Workstation oder Nutzer zu machen bzw. es für alle gleich. Das bringt den Vorteil, dass Funktionen bei der Einstellung stnWorkStation immer die gleichen Module geladen haben, egal, wer den Rechner benutzt (dazu kommt aber noch der SecurityLayer, welcher Benutzerabhängig ist). Bei der Einstellung stnUser wird der Username benutzt, so dass ein User auf allen Rechner mit "seinen" Modulen und Funktionen arbeiten kann.
HookTableSuffix : gibt den Suffix der Hook-Tabelle an, wo die vorgebauten dynamischen Funktionen gespeichert werden. Je nach Einstellung in StoreTableName wird der Name der Tabelle dann <UserName>_<HookTableSuffix> oder <ComputerName>_<HookTableSuffix> oder eben nur <HookTableSuffix> bei der Einstellung stnUserDefined.
PluginTableSuffix : siehe HookTableSuffix, nur eben für Module
für beide wird in der read-only-property HookTable und PluginTable der so zusammengesetzte Name angezeigt zur Designzeit.
Name : wieder mal der Name der Komponente
Password, Role und User : sind für die Datenbank-Komponente
Transaction : die Transaktions-Komponente, in dem Fall von FIBPlus

Es fehlen noch Funktionen zum erzeugen der DataSets für DB-unabhängige Programmierung, der Code ist schon da, muss aber eben noch übertragen werden aus dem ehemaligen Objekt in die neue Komponente. Ausserdem schreibe ich noch am Funktionszeiger-Mapping für TQuery-Objekte, weiss aber noch nicht, ob es funktioniert, ista uch nicht so wichtig, wird es wohl eh nicht in das aktuelle Release schaffen.

Ausserdem gibt es jetzt eine non-visual-component TERPGlobalVars, welche global Variablen speichert und lädt und deren Inhalt über den HookClient von überall abfragbar bzw. setzbar ist. Diese habe ich zur richtigen Komponente umgebaut, um den Code zu reduzieren im Router.

Nichts desto trotz würde mich mal noch einiges an Meinungen interessieren. Man schreibt es ja nicht nur wegen Verkauf, sondern wünscht sich auch Feedback

Grüsse aus Caracas

Hört sich alles sehr interessant an, und für mich ist auch die Namensgebung verständlich. Erst ein Praxisttest allerdings wird zeigen, ob es für meine Zwecke verwendbar ist. Wird das Framework auch mit Sourcen zukünftig angeboten ?

Leider kann ist die Website nicht erreichbar, wird da gerade umgebaut ?

natürlich wird es auch mit Source angeboten. Manche Erweiterungen/Anpassungen gehen ja eigentlich auch nur mit Source. Gerade, weil es ein Framework ist und ich nicht ALLES voraussehen kann Aus diesem Grund wird viel mit Custom-Komponenten gemacht (wo es Sinn macht), so dass später die entsprechenden Anpassungen gemacht werden können.

Bsp.: TERPCustomBaseDB implementiert nicht viel. Mehr stellt es nur die notwendigen Schnittstellen zur Verfügung. Es werden natürlich ensprechende Komponenten mit der finalen Implementierung zur Verwendung als auch als Beispiel zur Verfügung gestellt. Man steht also nicht im Dunkeln, sondern kann sich bei den abgeleiteten Datenbank-Komponenten anschauen, wie es implementiert wurde und es für "seine" Datenbank (falls noch keine Komponente verfügbar ist von mir) anpassen (meist ist es SQL austauschen und mit einer anderen Database/Transaction-Komponente verbinden, sowie Login anpassen). Das sollte aber in ein paar Stunden zu schaffen sein.

Btw... die neue Domain ist da, die Website ist jetzt unter www.erp-components.com zu finden