MVVM Framework für Delphi

[Daniel]

Hast Du dafür eine Quelle?

[mkinzler]

Stevie hat schon den Grund genannt. Aber der Insider hat da natürlich mehr Einblick.

Sogar mehr als die Autoren von XML!

Zitat von http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-formed:

2.11 End-of-Line Handling

XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating all of the following to a single #xA character:

the two-character sequence #xD #xA

the two-character sequence #xD #x85

the single character #x85

the single character #x2028

any #xD character that is not immediately followed by #xA or #x85.

The characters #x85 and #x2028 cannot be reliably recognized and translated until an entity's encoding declaration (if present) has been read. Therefore, it is a fatal error to use them within the XML declaration or text declaration.

[Insider2004]

Den Standard habe ich jetzt nicht gelesen, ich habe aber mehrere XML-Parser entscheidend mit entwickelt und wusste diesen Fakt.

[mkinzler]

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

[Uwe Raabe]

Zitat von mkinzler:

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

Genau das lese ich hieraus auch:

Zitat:

the XML processor MUST behave as if it normalized all line breaks in external parsed entities

Das verstehe ich so, daß der Parser alle erlaubten Line-Breaks akzeptieren und sich so verhalten muss, als ob nur LF vorkommen würde. Das heißt doch, daß in der XML alle erlaubten Line-Breaks vorkommen können (auch gemischt), ohne daß der Parser meckert.

Damit kann man dann auch XML-Dateien z.B. unter Windows mit irgendeinem Editor bearbeiten, auch wenn der beim Speichern CR+LF schreibt.

Aber bei dem genannten Problem ging es wohl auch gar nicht um das Lesen der "falschen" Line-Breaks, sondern um das Speichern in Normalform. Das kann man aber laut Stevie ja einstellen.

[Sir Rufo]

Zitat von Uwe Raabe:

Zitat von mkinzler:

Gültig ist aber das, was in der Definition steht. Hier sind mehrere Möglichkeiten erlaubt.
Und wenn mehrere XML-Parser nur Unixzeilenumbrüche akzeptieren, dann verhalten diese sich alle falsch.

Genau das lese ich hieraus auch:

Zitat:

the XML processor MUST behave as if it normalized all line breaks in external parsed entities

Das verstehe ich so, daß der Parser alle erlaubten Line-Breaks akzeptieren und sich so verhalten muss, als ob nur LF vorkommen würde. Das heißt doch, daß in der XML alle erlaubten Line-Breaks vorkommen können (auch gemischt), ohne daß der Parser meckert.

Damit kann man dann auch XML-Dateien z.B. unter Windows mit irgendeinem Editor bearbeiten, auch wenn der beim Speichern CR+LF schreibt.

Aber bei dem genannten Problem ging es wohl auch gar nicht um das Lesen der "falschen" Line-Breaks, sondern um das Speichern in Normalform. Das kann man aber laut Stevie ja einstellen.

Der Insider sieht eben alles nur von innen heraus. Und da eine XML-Datei intern nur mit dem UNIX-Zeilenumbruch arbeitet, setzt man vor dem eigentlichen Verarbeiten eine Logik, die diese Zeilenumbrüche einfach herausfiltert/umwandelt.

Wenn man sich also als Insider nur mit dem internen Kram beschäftigt (etwas anderes wäre für einen Insider undenkbar), dann sieht man eben nur diese Zeilenumbrüche.

Manchmal macht es eben auch Sinn sich von seinem Platz zu erheben damit man auch erkennt, was sich neben dem Teller noch so abspielt

[Phoenix]

Leute, bitte. Ihr wisst es doch eigentlich alle besser: Trolle bitte nicht füttern.

Mal zurück zu MVVM und grundsätzlich Strukturierung von Code:

Zitat von Dejan Vu:

Wenn ich die gängigen Programmierpattern (OCP, SRP, SOC usw.) stringent umsetzen will, dann führt kein Weg an einem MVVM-ähnlichen Konzept vorbei. Die Frage ist, ob ich das will, oder ob ich nicht doch pragmatisch das nicht ganz umsetze und manchmal ein wenig schludere.

Pragmatisch kann einem hierbei aber auch auf die Füße fallen. Mal ein Beispiel aus der Praxis:


Ein Team von Entwicklern (über die Zeit zwischen 3 und 6 Leute) sollte ein Softwaresystem bauen. Sie wussten es eigentlich schon damals alle besser: SOLID Prinzipien beachten, Unit- und Integration testen. Fremdkomponenten Kapseln vor dem Verwenden damit sie austauschbar bleiben etc.

Weil sie aber schnell fertig werden mussten, wurde das ganze über den Haufen geworfen und es wurde pragmatisch geschludert'. Oder anders/betriebswirtschaftlich formuliert: Es wurden während der Entwicklung technische Schulden aufgehalst, um durch diese Schulden eine schnellere time to market zu erkaufen. Das mag manchmal eine legitime Entscheidung sein.

Das Team war sich dessen schon bewusst, und sie wollten das was dort hingeschludert wurde auch immer später aufräumen (=die Schulden zurückzahlen). Die Business-seite wollte aber keine Schulden zurückzahlen (=Zeit und damit Geld in Aufräumen investieren), sondern neue Features / Produkte haben. Auch die mussten schnell gebaut werden, also wurden zusätzliche technische Schulden angehäuft.

Wie das nunmal in der Wirtschaft so ist: Auf Schulden werden Zinsen verlangt. Bei technischen Schulden machen sich diese Zinsen dadurch bemerkbar, das auf einmal die Wartungsaufwände steigen. Es werden mehr Bugs, die werden schwieriger zu fixen weil man keine gescheite Testabdeckung hat. Weil der Code sehr eng gekoppelt ist werden neue Features sehr teuer, etc.

Nach technischen Schulden kommt irgendwann die Überschuldung. Und dann irgendwann der Bankrott.

Fast-forward: Nur 4 Jahre später war das System an diesem Zeitpunkt angekommen. Die Ergebnisse:
Das Team war von dem Rotzcode den sie fabrizieren mussten so angewiedert, das bis auf einen das gesamte Team nahezu geschlossen die Firma verlassen hat. Das Know-how: Unwiderbringlich verloren. Das Software-System war als Grundstein für viele Projekte der Firma genutzt worden, die auf dieser suboptimalen Platform haben aufsetzen müssen. Die Weiterentwicklung war ohne Entwicklungsteam komplett eingebrochen, was die Projekte die darauf aufgesetzt haben massiv zurückgeworfen hat. Das System ist inzwischen in einem Zustand, das man es nur noch wegwerfen und nicht mehr weiterentwickeln kann.

Kurzum: Zwischen 12 und 21 Personenjahre Entwicklung direkt an dem System, plus weitere unzählige in den Projekten die darauf basierten sind für die Katz. Die Firma hat viele Top-Performer verloren. Den tatsächlichen wirtschaftlichen Schaden auszurechnen traut sich niemand.

Das ganze muss jetzt nochmal neu gebaut werden. Diesmal richtig: Unpragmatisch und SOLIDe. Wartbar. Erweiterbar. Flexibel. Die ganzen Projekte die darauf aufbauen migriert werden.

Hätte man damals den Pragmatismus beiseite gelassen, nicht geschludert und gleich den Overhead den gute Software nun einmal kostet auch in Kauf genommen, wäre es nie dazu gekommen. Ich sehe die Investition in eine gute Architektur, SOLID und Tests inzwischen wie eine Versicherung. Die Police bezahlt man vorher, aber sie sichert einen davor ab, schlechte Software zu produzieren die einen hinterher deutlich mehr, im schlimmsten Fall bis hin zum Totalverlust des Geschäftes kosten kann.

[vagtler]

Zitat von mkinzler:

Stevie hat schon den Grund genannt. Aber der Insider hat da natürlich mehr Einblick.

Sogar mehr als die Autoren von XML! [...]

Das ist jetzt aber sehr Off-Topic, oder nicht?

[mkinzler]

Sorry, ich werde in Der Zukunft die Schauze halten!!!!!!