Die wichtigsten Einstiegspunkte der Code-Base

Die Code-Base lässt sich für den Einstieg in fünf Kernbereiche sortieren: App-Start, Runtime-Wiring, Cloud-/Storage-Layer, Datenbasis und Library-/Prompt-Konfiguration. Danach folgt ein Beispiel-Workflow, der die eigentliche Page-Logik aufzeigt.

Reise 1: Der Startpunkt ist marketinggpt/app.py

Kurz gesagt: Diese Datei startet die komplette Web-Anwendung und verbindet die Oberfläche mit den API- und Page-Routen.

marketinggpt/app.py baut die eigentliche Flask- und Dash-App, legt den globalen server an, erstellt den API-Blueprint router und registriert die Page-Routen aus dem Ordner marketinggpt/pages. Die Sidebar und das Oberflächenlayout werden hier ebenfalls mitgebaut.

Wichtig ist hier vor allem die Verbindung:

server = Flask(__name__) erzeugt den HTTP-Server-Container.
app = dash.Dash(...) erzeugt die Dash-Web-Anwendung, die an den Flask-Server gehängt wird.
setup_routes(router) registriert die API-Routen der einzelnen Seiten.

Der wesentliche Follow-up-Effekt ist, dass die App-Initialisierung die zentrale Runtime-Umgebung aus marketinggpt/python_functions/energyai_elements.py anstößt, bevor die Seiten ihre Ajax-/Route-Handler bereitstellen können.

Reise 2: Die zentrale Infrastruktur steht in marketinggpt/python_functions/energyai_elements.py

Kurz gesagt: Diese Datei baut die Laufzeit-Umgebung der App: Rollen, globale Objekte, LLM-Interfaces und zentrale Services.

marketinggpt/python_functions/energyai_elements.py ist die Datei, in der die App ihren Global-State aufzieht.

Sie definiert Rollen-/User-Informationen, zentrale Hilfs- und Streaming-Objekte sowie die großen Laufzeit-Services:

DATA_LOADER lädt die Produkt-/Dokumenten-Datenbasis.
CONCISE_PAGE_LOADER ist die Loader-Klasse für Concise-Page-Funktionen.
UNITS_LOADER und PRODUCT_LOADER bauen die Unit- und Produktstruktur für die Seiten auf.
LIBRARY_MANAGER liefert Prompt-/Library-Konfigurationen und Zugriff auf Cloud-Assets.
LIB_INDEX ist die Index-/Such-Hilfsschicht.
OAI / OAI2 sind die OpenAI-/Azure-OpenAI-Interface-Objekte, die die LLM-Kommunikation kapseln.

Die Seite bzw. die API-Logik baut darauf auf. Das ist der Runtime-Knoten, der den Rest der App überhaupt erst in einen verständlichen Zustand bringt.

Reise 3: Die Cloud-/Storage-Schicht ist marketinggpt/python_functions/s3connect.py

Kurz gesagt: Diese Datei ist die Brücke in die Cloud-Datenquelle, ohne die die App viele Produkt- und Library-Daten nicht laden könnte.

marketinggpt/python_functions/s3connect.py ist der Cloud-/Storage-Connector der Anwendung.

Was ist hier definiert?

Die Klasse s3Client kapselt die S3- und Storage-Calls.
Der Bucket ist energyai-analyse.
Die persönlichen/shared S3-Prefixe und Cloud-Folders werden hier mit definiert und adressiert.
Methoden wie read_json2DF(), write_DF2json(), read_csv2DF(), download_folder(), upload_folder(), list_files() und get_latest_modification_date() bilden den Zugriff auf die Datenquelle.

Welche Objekte kommen von wo?

boto3 wird hier über die Python-Umgebung verwendet.
Die Klasse wird von vielen anderen Layern instanziiert, unter anderem marketinggpt/python_functions/LibraryManager.py, marketinggpt/python_functions/Dataloader.py, marketinggpt/python_functions/units_loader2.py, marketinggpt/python_functions/product_loader.py, marketinggpt/python_functions/concise_page_loader.py und marketinggpt/python_functions/cache_refresh.py.

Das ist der Datenspeicher-Hintergrund. Du solltest das verstehen, weil die App vieles nicht lokal, sondern aus S3-Cloud-JSONs und Cloud-CSV-Dateien lädt.

Reise 4: Die Datenlage wird in marketinggpt/python_functions/Dataloader.py vorbereitet

Kurz gesagt: Diese Datei holt Produkt- und Dokumentdaten aus den Quellen und stellt sie der App als aktive Datenbasis zur Verfügung.

marketinggpt/python_functions/Dataloader.py bringt die Laufzeit-Daten in den Zustand, den die App später in den Business-Workflows verwendet. Es ist also nicht die oberste Route, sondern die Schicht, die die Datenbasis für die Page-Funktionen formt.

In der Praxis bedeutet das:

__load() startet die Dateninitialisierung beim Objekt-Aufbau.
downloadYAML() holt die Benutzer-DB-Definitionen aus dem lokalen/Cloud-Kontext.
search() liefert die Such-/Filter-Logik auf den Datenbasis-Frames.
upload() / upload_settings() speichern Daten und Rahmenkonfiguration wieder zurück.

Diese Datei ist daher wichtig, weil sie die Art der Produkt-/Dokumenten- und Daten-Integration sichtbar macht, die die App später in den Seiten verwertet.

Reise 5: Die Bibliotheks-/Konfigurationslogik ist marketinggpt/python_functions/LibraryManager.py

Kurz gesagt: Diese Datei macht die konfigurierbaren Texte, Prompts und Parameter für die App nutzbar.

Der LibraryManager ist die Bibliotheks- und Prompt-Konfigurationsschicht der App.

Im Kontext der Code-Base sind die sogenannten Libraries keine Python-Pakete, sondern inhaltliche, von der App genutzte Business-Assets wie Terminologie, Phrasen, Examples, Requirements, Document-Structure, Start-Messages, Parameter-Defaults und OpenAI-Key-Definitionen, die als JSON/DF aus S3 geladen und bei Bedarf in der Laufzeit wieder hochgeladen werden.

Er liest Konfigurations- und Library-Objekte ein, die in der Laufzeit im System eine Rolle spielen. Dabei werden Informationen wie Terminologie, Prompt-Defaults, Parameter- und Struktur-Definitionen zusammengeführt. Die Arbeit geschieht im Zusammenhang mit den S3-/Cloud-Assets, die über den Storage-Layer zugänglich gemacht werden.

Die Kernlogik darin ist:

load() baut die Library-Landschaft aus den S3-/Cloud-Objekten auf.
getLibraries() liefert die konkrete Library als DataFrame oder Dictionary zurück.
FERNET_KEY wird hier verwendet, um sensible OpenAI-Keys oder ähnliche Secrets im Systemkontext zu entschlüsseln.

Für die erste Orientierung ist dieser Layer wichtig, weil die UI-Seiten nicht alles selbst definieren, sondern auf Libraries zurückgreifen.

Beispielhafte Business-Page: marketinggpt/pages/generation.py

Diese Datei zeigt den ersten echten Nutzungspfad der App: ein Benutzer fordert einen Text oder Output an und die App baut daraus eine Antwort.

marketinggpt/pages/generation.py meldet die Dash-Page an, baut die UI- und Callback-Logik und definiert zentrale API-Routen wie get_generation_prompt, generatev2 und get_examples im Router-Setup. Das ist der Ort, an dem der Nutzer auf ein konkretes Ergebnis zusteuert und die eigentliche Pipeline sichtbar wird.

Es arbeitet dabei mit den zentralen Laufzeit-Objekten zusammen:

DATABASE liefert die Runtime-Daten für Dokumenttypen, Textbausteine und Produkt-Kontext.
stream_oai() und start_stream_oai() sind die Streaming-Hooks, die die LLM-Ausgabe in die UI-/API-Response stellen.
Die Page holt also ihre Konfiguration und Inputs aus dem Runtime-State und lässt die LLM-Ausgabe durch den zentralen Stream laufen.

Die Reise in einem einfachen Flussdiagramm

marketinggpt/app.py startet Flask + Dash.
marketinggpt/python_functions/energyai_elements.py baut die globalen Objekte und den privaten Runtime-State.
marketinggpt/python_functions/s3connect.py liefert die Cloud-Datenquelle.
marketinggpt/python_functions/LibraryManager.py liest die “Libraries” aus S3.
marketinggpt/python_functions/Dataloader.py erweitert den Datenkontext der Runtime-Objekte.
Die Page-Route verwendet die zentralen Objekte und liefert ein LLM-Streaming- oder Text-Output zurück.