MVVM Framework für Delphi

[Sir Rufo]

Auch wenn ich Stevie da jetzt auf die Füsse trete, aber für mich ist weder DSharp noch Spring4D wirklich einsetzbar, da dieses nicht auf den ARC Plattformen komplett funktioniert.

Eigentlich schade, denn gerade bei Spring4D sind viele der Basics schon implementiert, die man für MVVM dringend benötigt - aber wenn man es nicht benutzen kann, was bringt es dann.

Zu DSharp hat Stevie aber schon gesagt, dass er das in der nächsten Zeit wieder anfassen möchte und auch aktive Mitstreiter herzlich willkommen sind.

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen :mrgreen:

[mkinzler]

Zitat:

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen

Und wenn nicht, schubse ich Dich gern ;)

[Lemmy]

Zitat:

Zitat von Sir Rufo (Beitrag 1286817)

Zu DSharp hat Stevie aber schon gesagt, dass er das in der nächsten Zeit wieder anfassen möchte und auch aktive Mitstreiter herzlich willkommen sind.

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen :mrgreen:

Danke...

Zitat:

Zitat von mkinzler (Beitrag 1286818)

Zitat:

So, jetzt habe ich mich wohl gerade in den Pool der aktiven Mitstreiter geworfen

Und wenn nicht, schubse ich Dich gern ;)

Da helfe ich auch gerne.. also beim Schubsen... :-)

[Stevie]

Hab grad eine Änderung in DSharp/develop gepushed, die es dir ermöglichen sollte, das Calculator Demo zu kompilieren (getestet mit Spring4D 1.0 und 1.1).

Virtual Treeview wird für das Projekt jetzt nicht benötigt, aber ich glaub der hängt über den TVP zumindest irgendwo im MVVM Code - läuft aber auch mit der aktuellsten Version.

In DSharp/feature/spring4d-compatibility ist der MVVM Teil noch nicht umgestellt worden, daher funktionierts dort nicht.

Wie schon gesagt, die Arbeit am MVVM Teil liegt seit einer Weile aus Zeitmangel und anderer Prioritäten (Spring4D, TestInsight) etwas brach.

Zitat:

Zitat von Sir Rufo (Beitrag 1286817)

Auch wenn ich Stevie da jetzt auf die Füsse trete, aber für mich ist weder DSharp noch Spring4D wirklich einsetzbar, da dieses nicht auf den ARC Plattformen komplett funktioniert.

Da und da kannst du mir/uns gerne auf die Füße treten, solang du willst - "funzt nicht" ignorier ich aber generell. :)

Gerade bei Spring4D haben wir extra einen Entwickler, der alle Features auf Mobile testet und auch einsetzt.

[Thomas_K]

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Gerade für die Mobile-Entwicklung will ich auf MVVM setzten, was für in System/Prinzip benutzt ihr in euren Apps?

[Stevie]

Zitat:

Zitat von Thomas_K (Beitrag 1286832)

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Packages kannste die für XE6 nehmen und umbenennen. Zeilenumbruch wird am git eol handling liegen, hab da noch keine .gitattribute Datei reingepackt.

[Insider2004]

Zitat:

Zitat von Thomas_K (Beitrag 1286832)

@Stevie

Ich habe das Calculator Projekt unter XE7 zum laufen gebracht, doch Packages für XE7 sind nicht in DSharp/develop vorhanden. Warum besitzen die xml Projektdateien eigentlich einen Unix Zeilenumbruch? Nur so eine Frage am Rande, egal jetzt ist erstmal schön ein ordentliches MVVM Beispiel für Delphi zu haben, Danke.

Gerade für die Mobile-Entwicklung will ich auf MVVM setzten, was für in System/Prinzip benutzt ihr in euren Apps?

Weil die XML-Norm Unix definiert.

[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:

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.