Die Projekt Architektur, die mit 4D v18 eingeführt wird, ist eine wichtige Evolution für 4D Anwendungen. Ein Projekt besteht aus textbasierten Dateien, so dass Ihr 4D Code vom Menschen lesbar ist und die Leistungsstärke von Source Control Tools nutzen kann. Die Projekt Architektur unterstützt auch nativ die meisten der aktuellen Libraries und Oberflächen. 

Weitere Ausführungen zum Projektmodus in 4D finden Sie unter developer.4D.com.

Sie können eine 4D Binärdatenbank (.4db Datei) in ein Projekt konvertieren, indem Sie einen einfachen Menübefehl Ihrer 4D Single-User Applikation verwenden. Da der Export eine neue Version der vorhandenen Anwendung erstellt, werden die Originaldateien nie angerührt. Sie können also Ihre Anwendung so oft konvertieren, bis Sie mit dem Ergebnis zufrieden sind. Öffnen Sie Ihre .4db Anwendung, machen Sie ein paar Änderungen, konvertieren sie erneut und testen das Ergebnis. Jede neue Konvertierung überschreibt die vorherige. 

Beachten Sie, dass ein Export nur in eine Richtung läuft:

• Wurde eine 4D Anwendung als Projekt exportiert, werden beide Versionen voneinander unabhängig.
• Ein Projekt lässt sich nicht als eine .4db Datei exportieren.
• Da Projekte auf den neuesten Technologien beruhen, unterstützen sie einige ältere Feautures nicht. Diese werden soweit wie möglich automatisch aktualisiert oder zeigen Konvertierungsfehler an (siehe Abschnitt unten Die Konvertierung prüfen). 

Beim Konvertieren einer vorhandenen 4D Anwendung in ein Projekt bleibt die .4db Datei unangetastet. Neben Ihrer Datei .4db wird ein neuer Ordner mit Namen "Project" angelegt, der alle notwendigen Dateien enthält.

Hinweis: Gibt es auf derselben Ebene wie Ihre .4db Datei bereits einen Ordner "Project" (z.B. weil bereits eine Konvertierung durchgeführt wurde), wird er ersetzt.

Um eine Anwendung in ein Projekt umzuwandeln:

1. Öffnen Sie die Anwendung zum Konvertieren.
2. Wählen Sie Datei > Exportieren > Struktur in Projekt.
     
   

Hinweise:

• Dieser Menüeintrag ist nur bei 4D Single-User verfügbar.
• Dieser Menüeintrag ist nur verfügbar, wenn eine Binärdatenbank geöffnet ist - in Projektdatenbanken ist er deaktiviert.
• Sie können auch den Befehl Export structure file verwenden.

Ist die Konvertierung erfolgreich und werden keine blockierenden Fehler gefunden, erscheint folgendes Dialogfenster:

• Log anschauen: Markiert das Logbuch der Konvertierung auf Ihrer Festplatte. Sie sollten diese Datei unbedingt ansehen, da die Konvertierung u.U. einige Teile der Anwendung verändert haben kann (siehe Abschnitt unten Die Konvertierung prüfen).
• Öffne Projekt: startet die 4D Anwendung neu und lädt das Projekt. 

Beim Konvertieren bleibt die Datendatei unangetastet, nur Entwicklungselemente werden konvertiert. Nach der Konvertierung können Sie weiterhin die Datendatei mit der .4db Strukturdatei öffnen.

Das Projekt verwendet die Ordner Resources, Logs und Web automatisch und ohne Änderung. Das vereinfacht die Konvertierung und Testen des Projekts. 

Beim Konvertieren wird ein neuer Ordner "Project" auf derselben Ebene wie Ihre .4db Strukturdatei angelegt. Er enthält Ihre gesamte Anwendungsentwicklung als Textdateien: Formulare, Struktur, Methoden, Trigger, Menüs, Hilfetipps, Listen. Er enthält außerdem eine .4DProject Datei, das ist Ihre konvertierte 4D Projekt Hauptdatei:

Öffnen Sie die .4DProject Datei mit Ihrer 4D Applikation, verwendet das Projekt die gleichen Ordner Resources und Web wie die vorhandene .4db Datei. Das vereinfacht das Testen Ihres Projekts.

Sie können weiterhin Ihre .4db Datenbank öffnen, bei Bedarf Änderungen ausführen (siehe unten), dann erneut exportieren und testen. Sie können diesen Vorgang wiederholen, bis Sie mit der Konvertierung zufrieden sind.

Beim Konvertieren wird standardmäßig ein Logbuch im JSON Format erstellt, das auf alle Probleme hinweist, für die eine Aktion erforderlich ist. Die Meldungen sind in drei Kategorien gegliedert (Eigenschaft "severity"). Hier ein Beispiel:

• info: Beschreibt eine notwendige Aktion, die der Converter automatisch ausführt, und die keine Auswirkung auf die Oberfläche oder Funktionsweisen der Anwendung haben. Haben Sie beispielsweise Bilder in der Bildbibliothek, exportiert 4D sie in den Ordner Resources der Anwendung (siehe Beispiel oben).

• warning: Beschreibt eine notwendige Aktion, die der Converter automatisch ausführt, und die evtl. zu Unterschieden in der Oberfläche oder Funktionsweisen der Anwendung führen können, aber nicht den Betrieb der Anwendung beeinträchtigen. Bei Warnungen müssen Sie in der Regel prüfen, wie sich die Konvertierung auf Ihren Code auswirkt. Warningen erscheinen z.B., wenn nicht unterstützte Einstellungen zur Kompatibilität, wie "Unicode Modus" oder "Optionsfelder nach Namen gruppieren"  automatisch aktiviert werden.

• error: Beschreibt ein Problem, das Ihren Eingriff erfordert und korrigiert werden muss. Es kann den Betrieb der Anwendung beeinträchtigen. Es gibt beispielsweise einige Formularobjekte, die nicht mehr unterstützt werden, wie z.B. Invertierte Schaltfläche. In diesem Fall müssen Sie vor dem Start der Konvertierung die Schaltfläche in der  .4db Datei in eine 3D Schaltfläche umwandeln. 

Sind Bearbeitungen in der .4db Datei erforderlich, ändern Sie den Code oder das Formular entsprechend ab und exportieren die Struktur erneut. Wiederholen Sie den Vorgang, bis Sie mit dem Ergebnis zufrieden sind. 

Beim Konvertieren werden einige der veralteten 4D Technologien in modernere Implementationen konvertiert, andere werden geändert oder nicht berücksichtigt. Das gilt für folgendes:

• Die Bildbibliothek existiert in Projekten nicht mehr. Beim Konvertieren exportiert 4D alle Bilder in den Ordner Resources der Anwendung.
• Formularobjekte und deren Eigenschaften wurden aktualisiert. Sie verwenden jetzt dieselbe Grammatik wie Dynamische Formulare. Veraltete Teile werden nicht mehr unterstützt. 
• Untertabellen (überholt seit 4D v11, siehe ) werden in Projekten nicht unterstützt.
• Verschachtelte Gruppen von Formularobjekten werden in Projekten nicht unterstützt (Gruppen werden nur auf einer Objektebene implementiert). Sie werden beim Konvertieren extrahiert und auf die niedrigste Stufe gesetzt.
• Die Eigenschaft Tabfähig wird in Projekten nicht unterstützt, da die Eingabereihenfolge über die Collection entryOrder in Dynamische Formulare verwaltet wird. Beim Konvertieren wird die Collection automatisch gemäß der vorgegebenen Eingabereihenfolge gefüllt (Objektreihenfolge per Tabulator). Sie sollten in der Projekt-Anwendung prüfen, ob die Eingabereihenfolge im Formular korrekt konvertiert wurde.
• Kompatibilitätseinstellungen der Anwendung werden wie für eine neue Anwendung zurückgesetzt. Im Konvertierungsprotokoll können Sie den Status dieser Einstellungen für Ihre Anwendung überprüfen.
• Alle Kompatibilitätsoptionen von Formularen (z.B. "Dynamische Anpassung","Mit Einschränkungen") werden wie für ein neues Formular zurückgesetzt.
• Stilvorlagen werden als CSS Stilvorlagen in JSON Dateien exportiert und im Ordner "/SOURCES" mit folgendem Namen gespeichert:
• "styleSheets_mac.css" für macOS,
• "styleSheets_windows.css" für Windows.
  
  Angewandte Stilvorlagen werden als "class" Attribute zu JSON Beschreibungen der Formularobjekte hinzugefügt. 
• Formularobjekte erweitern sich automatisch nach unten, wenn die CSS- oder Plattform-Schriftgröße zu groß ist. Dadurch wird verhindert, dass Text abgeschnitten wird.
• Die Sichtbarkeit der Markierungen der Ausgabesteuerung bleibt nicht erhalten, wenn Sie Formulare in Projekten schließen und wieder öffnen. 
• Explorer Kommentare werden als Documentation Markdown Dateien exportiert (nur Text). Weitere Informationen dazu finden Sie unter developer.4d.com. 

Folgende Formularobjekte und Eigenschaften erfüllen nicht die Anforderungen für aktuelle Oberflächen und sind jetzt überholt. Dynamische Formulare unterstützen sie nicht und können im Konvertierungsprotokoll eine Warnung oder einen Fehler generieren (siehe Kommentar). 

Aufgrund geänderter Verhaltensweisen in Projekten kann das Rendern von Formularobjekten in Projekten anders ausfallen, wenn Befehle zum Formatieren mit bisher standardmäßigen bzw. fehlenden Parametern verwendet werden.

Folgende Einstellungen für Felder sind überholt und werden bearbeitet oder zeigen im Konvertierungsprotokoll einen Fehler (siehe Kommentar).  

Folgende Editoren und Features der Toolbox sind überholt und werden in Projekten nicht unterstützt:

Beim Konvertieren werden vorhandene 4D Benutzer und Gruppen automatisch aus der .4db Datei extrahiert und in der Datei directory.json des Projekts gespeichert. 

Da der Code in Projekten in offenen Textdateien gespeichert ist, arbeitet das 4D Zugriffssystem für Benutzer anders als in binären Anwendungen. Es gilt folgendes:

• Im Einzelplatz ist das Kennwortsystem immer deaktiviert:
  • Es erscheint kein Dialogfenster zum Anmelden 
  • Der aktuelle Benutzer ist immer der Designer
  • Die Einstellungen für SQL Server oder Web Server werden ignoriert (lassen sich aber für Client/Server Einsatz setzen).
• Es gibt keinen Unterschied zwischen Benutzern, die der Designer oder der Administrator angelegt hat.
• Es lassen sich keine Zugriffsgruppen oder Gruppen mit Eigentümer zu Menüs, Methoden und Formularen zuordnen. Der Schutz von Code sollte über das Source Control Tool verwaltet werden.
• Benutzer und Gruppen IDs (Referenzen) werden während der Sitzung dynamisch verwaltet, jedoch nicht gespeichert.

Hinweis: Im Client/Server-Modus funktioniert die Zugriffskontrolle der Benutzer in Projekt Anwendungen genauso wie in binären Anwendungen. Dagegen wird der Zugriff über Gruppen auf Menüs, Methoden und Formulare nicht unterstützt (siehe Hinweis zur Sicherheit).

Daraus folgt nach der Konvertierung:

• Die Benutzerart "Entwickler" existiert nicht mehr, alle Benutzer (außer Designer und Administrator) sind vom Typ "Benutzer". 
• Die Art Gruppe und Gruppeneigentümer werden entfernt.
• Statische Benutzer IDs und Gruppen IDs werden nicht beibehalten. Davon ausgenommen sind der Designer (ID=1) und der Administrator (ID=2).
• Im Journal der Datenbank wird die Information "user4D_id" ersetzt mit "user4D_alias", was das 4D Benutzer Alias ist (4D Benutzername, wenn kein Alias gesetzt wurde).

Hinweis zur Sicherheit: 

• Da Projekt Anwendungen keine Gruppenzuweisungen zu Methoden (sowie zu Menüs und Formularen) unterstützen, lassen sich 4DACTION/ Urls oder 4D Write Pro/4D View Pro Formeln nicht über 4D Benutzerzugriff steuern. Hat Ihre Anwendung diese Art der Steuerung verwendet, müssen Sie die Datenbankmethode On Web Connection bzw. für Methoden das Attribut “Verfügbar durch 4D HTML Tags und URLS (4DACTION...)” und für Formeln den Befehl SET ALLOWED METHODS verwenden.

• Wenn Sie eine Client-Server-Projekt-Applikation erstellen, die den Zugriff über User und Gruppen steuert, stellen Sie sicher, dass Sie die Datei directory.json in den Settings-Ordner des Data-Ordners kopieren, damit sie in der resultierenden Server-Applikation verfügbar ist. 
  

Sind eigene Objektbibliotheken (.4il unter Windows oder .4dlibrary auf macOS) vorhanden, müssen sie separat exportiert werden, wenn Sie diese in Ihren Projekten verwenden wollen. Weitere Informationen dazu finden Sie unter diesem Blog Post.  

Die 4D Projektverteilungsstrategie basiert auf .4dz gepackten Dateien, bei denen die gesamte Struktur read only ist. Dies ist der Fall für zusammengeführte Applikationen oder kompilierte Komponenten. Folglich funktionieren Befehle, die die Struktur ändern, nicht und sollten nicht in bereitgestellten Applikationen verwendet werden. Wenn sie aufgerufen werden, bewirken sie nichts oder werfen einen Fehler, je nach Kontext. 

Beachten Sie, dass das Ändern von Strukturdateien in bereitgestellten Applikationen aus den folgenden Gründen nicht empfohlen wird:

• es verhindert die Installation zusammengeführter Applikationen in regulären Applications-Ordnern, auf die Benutzer manchmal keine Schreibrechte haben
• er bricht die Signatur signierter Applikationen, wodurch das Betriebssystem davon ausgehen kann, dass sie infiziert wurden
• es macht die Aktualisierung von eingesetzten Strukturversionen sehr komplex, wenn lokale Änderungen gespeichert werden müssen. 

Wenn Sie jedoch unbedingt das .4dz-Format vermeiden und Ihren "Projekt"-Ordner so belassen wollen, wie er ist, damit Sie seine Quelldateien auf bereitgestellten Sites ändern können (was, wie oben erläutert, nicht empfohlen wird), könnte der PackProject  Schlüssel für Sie interessant sein. 

Hier ist die Liste der Befehle, die die Struktur verändern:

Wenn eine Datenbank in ein Projekt konvertiert wird, wird der Backup-Achivzähler zurückgesetzt. Das bedeutet, dass die erste Sicherungsarchivdatei in einem konvertierten Projekt den Namen myBase-0001 erhält, unabhängig von der Sequenznummer der letzten Archivdatei in der Binärdatenbank.

Der Zähler des Backup-Archivs ist eigentlich mit der Datenbankstrukturdatei verknüpft. Wenn Sie eine .4DB-Datei umbenennen oder verschieben, und erst recht, wenn Sie sie in ein .4DProjekt konvertieren, wird ein neuer Backup-Zähler gestartet.

Passt Ihre konvertierte Anwendung und Sie möchten nun im Projektmodus arbeiten, können Sie das verwendete Verzeichnis (directory) bereinigen:

1. Entfernen Sie Ihre.4db und .4dindy Dateien aus dem Anwendungsordner (legen Sie diese  z.B. in das Backup Verzeichnis). Auf macOS müssen Sie evtl. zuerst den Befehl Show package aufrufen oder die Endung beim Ordner .4dbase entfernen. 
2. Auf macOS entfernen Sie während der gesamten Entwicklungsphase die Endung beim Ordner .4dbase. Da Sie mit Textdateien arbeiten und diese mit dem Source Control Tool verwalten, müssen Sie direkt darauf zugreifen können.

Soll die Datendatei automatisch geöffnet werden, wenn das Projekt auf andere Rechner übertragen wurde, können Sie für Übereinstimmung mit der Projekt-Architektur sorgen (siehe unter developer.4d.com):

1. Benennen Sie Ihre Datendatei um in "data.4dd".
2. Erstellen Sie einen Ordner mit Namen "Data" und legen Sie die Datei data.4dd in diesen Ordner
3. Speichern Sie den Ordner Data auf derselben Ebene wie den Projekt Ordner.