Hallo zusammen,
Im Anschluss an die Diskussion über Wochenendtarife und die Antwort von @pierre-gilles auf Gladys#2999 folgt hier der entsprechende Funktionswunsch.
Zuerst das Prinzip. Pierre-Gilles schlug vor, den Kern generisch zu halten und es externen Integrationen zu ermöglichen, neue Vertragstypen zu deklarieren, anstatt im Kern landesspezifische Fälle zu stapeln. Ich bin voll und ganz damit einverstanden, und beim Betrachten des Codes finde ich, dass es noch relevanter ist, als ich dachte: Die Architektur geht bereits in diese Richtung, es fehlt vor allem die Öffnung.
Zu beachten ist, dass @mutmut bereits einen Wunsch zur Verwaltung der Tarife nach Tag, Saison und Ferien gestellt hat. Dieser ersetzt den seinen nicht: Sein Wunsch beschreibt den Nutzerbedarf, dieser beschreibt den technischen Mechanismus, der es ermöglichen würde, darauf zu reagieren, ohne den Kern zu überladen. Beide sind komplementär.
Was bereits existiert und in die richtige Richtung geht
server/services/energy-monitoring/contracts/contracts.calculateCost.js ist bereits ein nach Vertragstyp indexiertes Wörterbuch, bei dem jeder Eintrag eine Berechnungsfunktion mit einer einheitlichen Signatur ist:
(energyPricesAtConsumptionDate, consumptionDate, consumptionValue, systemTimezone, context) => cost
Das ist genau ein Erweiterungspunkt. Besser noch: Der Parameter context wird bereits verwendet, um externe Daten zu injizieren — Tempo erhält edfTempoHistoricalMap, d. h. einen Kalender mit Farbtagen, der anderswo abgerufen wird. Das Beispiel eines Vertragstyps, der von einer externen Datenquelle abhängt, ist also bereits etabliert.
Auf der Speicherseite sind hour_slots eine einfache freie Zeichenkette und subscribed_power ebenfalls. Eine externe Integration könnte dort codieren, was sie möchte, ohne das Schema zu berühren.
Was blockiert
Vier Hindernisse, vom schwierigsten zum einfachsten:
- Das SQL-Modell. In
server/models/energy_price.jsist die SpaltecontracteinDataTypes.ENUM(...ENERGY_CONTRACT_TYPES_LIST), undday_typeeinENUM(...ENERGY_PRICE_DAY_TYPES_LIST). Das ist das echte Hindernis: Das Hinzufügen eines Typs erfordert eine Datenbankmigration, was eine externe Integration nicht tun kann. - Die harte Liste
ENERGY_CONTRACT_TYPESinserver/utils/constants.js, die diesen ENUM und die Servervalidierung füttert. - Das Berechnungswörterbuch ist nicht registrierbar: Die drei Handler sind hart im Modul geschrieben.
- Das Frontend, mit
KNOWN_CONTRACT_TYPEShart inImportPrices.jsxund die Beschriftungen incontractTypesder i18n-Dateien.
Was ich vorschlage
a) contract und day_type von ENUM zu STRING wechseln, indem die Validierung in die Anwendungsschicht verschoben wird (gegen die Liste der registrierten Typen, Kern + Integrationen). Eine Namenskonvention pro Integration würde Kollisionen vermeiden, z. B. <service>:<type>. Das ist die strukturelle Änderung: Ohne sie ist keine externe Erweiterung möglich.
b) Eine Registrierungs-API auf dem Service anbieten, im Sinne von:
gladys.energyMonitoring.registerContractType({
id: 'edf-zen-week-end',
calculateCost: async (prices, date, value, timezone, context) => { ... },
});
Die Signatur ist bereits die der bestehenden Handler, sodass die drei aktuellen Typen zu diesem Mechanismus migriert werden könnten, ohne ihre Logik zu ändern — eine gute Möglichkeit, die API im Vorbeigehen zu validieren.
c) Das Import-Bildschirm durch Daten steuerbar machen: Die Liste der Typen und die Beschriftung kommen von den registrierten Typen, mit einem sauberen Fallback, wenn keine Übersetzung existiert. Der aktuelle Zeitfenster-Selektor bliebe das Standardverhalten.
d) Optional, für später: Erlauben, dass die Integration den Typ des Preis-Editors angibt, den sie benötigt, oder sogar ihren eigenen Bildschirm bereitstellt.
Mit diesem Ansatz könnte eine Integration „Energie Frankreich“ Zen Week-End, Tempo, die Angebote von Engie / OHM / Enercoop und die saisonalen Fälle von @mutmut unterstützen, ohne dass der Kern den Kalender der französischen Feiertage kennen muss.
Eine offene Frage
Heute leben die Tariftabellen im Gemeinschaftsdepot energy-contracts, und das ist wertvoll: Wenn jemand die EDF-Preise aktualisiert, profitiert jeder davon. Wenn die landesspezifischen Typen in eine externe Integration wandern, wo gehen die Preisdaten hin? Bleiben sie in energy-contracts mit der Integration, die nur die Berechnungslogik hinzufügt, oder ziehen sie ebenfalls um?
Ich habe eine Präferenz für die erste Option — ein einziges Depot für Tabellen beibehalten, gemeinsam genutzt, und nur den Geschäftslogik-Code herausnehmen — aber das ist wirklich eine Frage, keine festgelegte Position.
Danke!
!!! Ich glaube nicht, dass ich Zeit haben werde, dein Bild in naher Zukunft zu testen, aber das beantwortet mein Problem (und viele andere nebenbei 
)
