$1 mit $schritte++; oder so

[Beat]

$UnClean{integer_one_char}
Willst du das jedes mal überprüfen? Das ist nicht wartbar.
Wie wenn dir dann einfällt, dass dieses Feld nun zwei Integerzeichen lang sein darf?

Üblicherwiese fällt das in den Aufgabenbereich des Formulagenerators. Du erzeugst ein Formular mit Formularfeldern und wenn du dies zentral machst, legst du dort auch die Definition welche Werte erlaubt sind ab.

Es gibt viele Formulare zu den gleichen Daten.
Ich fordere dass Validierung eher eine Eigenschaft des Datenmanagers ist.

mehr dazu folgt

Du erlaubst die Angabe einer Mailadresse.
Du hast die Wahl diese Angabe einmal zu validieren (soweit sinnvoll), oder unvalidiert zu speichern und dann das bei jeder Verwendung nachzuholen.
Das ist nicht praktikabel.

Wieso nicht? Ich nehme diesen Wert auf und habe danach ein Model mit einem Datenfeld auf  das ich mit einem getter zugreife datenmodel->mail() und das verwende ich.

OK, dann modularisierst du alle deine Feldtypen in ein eigenes Modul.
Das ist eine Frage ob einem das behagt.

Übrigens widersprichst du gerade oben. Ein Formularmanager ist ein Viewer der Daten. Nicht ein Model.

Ich denke weniger MVC-orientiert [1], sondern eher entlang zusammenfassender Datenbeschreibung. Das liegt vielleicht darin begründet, dass mir schwindlig wird, wenn ich mehr als drei Editor Tabs zum gleichen Framework offen habe.

[1] eventuell unterstelle ich etwas?

...

Und wie teilst du den Modulen mit, was der Inhalt von Feld XY formal sein darf?
Du brauchst für jedes Modul eine zentrale Erkundigungsstelle.

Die Parameter die reinkommen können so strukturiert sein

snipp...

Daten geparst

...snipp

Natürlich muss dann, z.b. das Forummodul Wissen, dass die id's Zahlen sein müssen und titel Text. Ob aber HTML zugelassen ist oder nicht, wird in einer Konfiguration gespeichert. Jetzt kann es aber sein, dass in einem Nachrichtensystem ebenfalls der Parameter titel verwendet wird, dort sind aber andere Filterkritierien wichtig, z.b. wenn sie per Mail verschickt wird, darf das Subjekt kein Zeilenumbruch enthalten, in einer Forumsnachricht spielt das keine Rolle. Es wäre also nicht hilfreich das zentral zu machen, zumal viele Parameter nur für einzelne Module nötig sind und daher gar nicht bearbeitet werden müssen.

Die Kontextspezifische Ausgabe ist natürlich auf eine sub oder ein Modul zu reduzieren, wobei dann dieser Ausgabefilter, wenn ich es recht verstehe, im Viewer eingebunden wird.

Für mich gibt es zwei Arten von Daten:
Userdaten und Programm-Eigenschaft-Daten.
Es ist auch für mich klar, dass ich diese verschieden organsisiere.
Eine modularisierung von Ausgabefiltern mache ich nur bei Programmen, bei welchen ich ein starkes Wachstum vermute. Das liegt wohl daran, dass bestimmte Filter so einfach sind, dass sie in einer sub gut unterkommen.

Zu deinem Datenbeispiel

Ich nenne das mal eine Vektor-Orientierte Datenstuktur. Alles zeigt auf etwas anderes als zusätzliche Quelle oder Festlegung.
Ich halte das durchaus für eine mögliche Struktur, die aber spezifische Arbeitsinstrumente bedarf, die den normalen Editor übersteigen. Du musst den gesamten Informationsfluss quer über Dateien zu einem Parameter surfen können um deine Baustelle zu erfassen.
Für mich aber gibt es Datentypen, und Userdaten gehören hierzu, die irgendwo einen abgeschlossenen Kontext bilden, und die frei von Ringförmigen Abhängigkeiten sein müssen. Ob ich sie als Tabelle speichere oder als hash baum, das ganze muss einen Anfasser haben, und ich muss die Daten letztlich auch frei machen können vom Werkzeug, in welchem diese Daten ja nur behandelt werden.
Aber auch für die Architekturdaten braucht es dann irgendwo eine Sicherheit, dass ein Baumartiges Konstrukt vorliegt. Wenn zirkulärschleifen entstehen, dann hat man oft schwer durchschaubare Vorgänge. Hier sehe ich eine potentielle Gefahr von solchen Vektor orientierten Strukturen. Vielleicht gerade im Zusammenhang mit der Dateizersplitterung.

Vielleicht nur um den Thread noch zu schliessen, die Frage:
Wie organisierst du diese Arbeit praktisch?

mfg Beat