Anregung zu Struktur in Textfiles

Nur als Anregung zu Struktur in Textfiles:

Ich würde mir wünschen
dass das bisherige Folder-/File-Name Gerüst
wie schon aus Exportieren/Struktur-In-Textdateien
im Konzept noch optimiert/geändert wird.

Auch sollen neben Folder-/File-Names
zusätzlich diverse Meta-Infos im File-Content
integriert werden.

Wann ein File-/Folder erstellt/geändert wurde
gibt das Filesystem zur Info.

Da aber sowohl Filesystem als auch Meta-Content-Infos
sowie auch z.B. eigene Methode-Comment-Header-Infos
aus diversen Gründen verfälschte Infos haben können,
ist es wichtig im Vergleich mehre Info-Quellen zur Verfügung zu haben.
Es gibt sehr sehr viele Gründe wo Datum/Zeit oder auch Namen/Kennungen
falsche Infos liefern. Man nehme nur als Beispiel einen uralten immer noch aktuellen Bug
wo im Multi-User-Betrieb der Code einer Objekt-Methode die mit Form-Objekt-Gruppe
im Form-Designer eingepastet wurde sich in die gerade geöffnete Projekt-Methode eines
anderen User verirrt oder umgekehrt die PM in die OM sich verirrt und einer der beiden
dann als verwaiste Methode im Struct-Check wiederzufinden ist.
In solchen Fällen bleibt dann nur noch der eigene Methoden-Commment-Header
um noch zu wissen wer wohin eigentlich gehört.

Ziel ist es also die wichtigsten Meta-Infos wie eindeutige Kennung
und Datum/Zeit auf mehreren Ebenen unabhängig zur Verfügung zu halten.

Nur mal als Beispiel eine Form-Objekt-Methode:

Generell sollten Folder- und File-Names die aus Namen/Kennungen der
jeweilige 4D-Objekte(Table/Forms/Methoden/…) generiert werden,
berücksichtigen dass das jeweilige Filesystem nicht alle Namen+Zeichen so abbilden kann
wie es 4D intern bisher möglich war diese zu erzeugen.
Z.B. Window: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file
Zitat: Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9
…meine Anmerkung dazu, natürlich haben viele ein 4D-Druckform “prn” genannt
und scheitern damit, weil ein gleichnamiger Ordner nicht angelegt werden kann.

In zumindest die ProjektMethoden(nicht OMs)
wird ohnehin schon eine Attributs Commentzeile beim Export von 4D eingefügt.
z.B. //%attributes = {}

Hier würde ich mir wünschen weitere Meta-Infos mit im Content als Comment zu haben.
Bei einer OM einer Table-Form z.B.
header4D {
“type”: “OM”,
“id”: “[contacts];“IN”.btnLoad”
“objName”: “btnLoad”,
“varName”: Null,
“formName”: “IN”,
“tableName”: “contacts”,
“tableNo”: 1,
“created”: “2019-04-29T13:00:00Z” ,
"lastChanged: “2013-04-29T13:00:00Z”
}

Zeitpunkt der Erstellung und letzter Änderung sollten zu jedem 4D-Objekt(Form/Table/Methode/…)
ohne Ausnahmen/Einschränkungen generell voll verfügbar sein und über Content-Meta-Infos ausgewiesen werden.

Eine Table-Form über die OrdnerNamen allein nur zur Verfügung zu stellen ist nicht ausreichend.
Hinzukommt das Table-Form im Ordner Table steckt und der hat mit Namen nur die TableNummer.
So ich habe jetzt 300-Ordner 1-300 für meine 300Tabellen,
was mir den Überblick wirklich schwer macht, denn wenn ich nur diese OrdnerNamen lese
dann weis ich nicht auswendig wie die Tabelle 252 eigentlich heißt.
Somit kann ich das File-Gerüst nicht interpretieren ohne eigene Software die erstmal
nachliest wie die Tabelle 252 eigentlich benannt ist indem sie die Meta-Infos aus catalog.4DCatalog
parsed/ausliest/qualifiziert/zuordnet.
Dieses Manko wäre nicht notwendig, wenn eben gleich jedes File im Content seine eigene Meta-Infos
gleich mit enthält.

wenn Ihre Bemerkungen als Feature Requests gesehen werden sollen, dann bitte im dazugehörigen Unterforum “Feature Requests” eintragen. Soll es aber lediglich der Kommunikation mit der Community dienen, dann ist es hier schon richtig.

Danke, ich wollte das nur mal als Anregung in den Raum werfen,
da es im deutschen-forum kein Unterforum “Feature Request” gibt
(also ich kann nur das englisch-sprachige “Feature Request” hier finden).

Neben dem ExportStrukturInTextfiles
wollte ich die Anregung vor allem rechtzeitig mal weitergeben
für zukünftiges Feature “4D-Project” und zukünftige Version-Control-Systeme die die Struktur in Textfiles
verwalten sollen.

So oder so wird mein Vorschlag “vollständige Meta-Infos im Content aller 4D-Objekt-Dateien”
vielleicht noch einen Weg in den FeatureRequest finden, zur Not auch in Englisch.
Mal sehen ob sich hier noch ein Zweiter meldet der das ähnlich sieht wie ich
und solche Meta-Infos (immer+überall uneingeschränkt) auch von Vorteil halten würde.