![]() |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
habe clean.bat gemacht und der Fehler kommt hier :
Delphi-Quellcode:
and (LType.IsInheritedFrom('TForm')
Zitat:
|
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
IsInherited ist eine 2fach überladene Methode des TRttiType class helpers in the DSharp.Core.Reflection. Auf die Gefahr hin, mich zu wiederholen: stelle bitte sicher, dass du auch das DSharp.Core Package neu kompiliert hast und nicht irgendwo noch eine alte Version davon liegen hast. Der Fehler deutet darauf hin, dass die Überladung der Methode, welche ich am 6. November (r204) hinzugefügt habe, nicht gefunden wird.
|
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Sorry, sorry....mein Fehler.
Aus irgendeinem Grund wurden nicht alle Dateien runtergeladen bzw aktualisiert. Ich habe alles noch mal neu runtergeladen und es läuft! Wenn ich Dich mal treffe, gebe ich nen Bier aus, okay? |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Zitat:
|
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Liste der Anhänge anzeigen (Anzahl: 1)
Nachdem ich beim ersten Versuch wegen diverser Probleme gescheitert bin habe ich heute in einem Testsystem noch einen weiteren Versuch unternommen (XE Prof).
Mein GData hat wieder angeschlagen. Da ich mit einem Testsystem arbeite, habe ich das mal ignoriert. Hier meine Schritte und Probleme, falls jemand allein auch nicht zurande kam: Ich habe folgende Ordner angelegt: Projekte\DSharp .\DelphiSorcery .\DelphiSpring .\VST Dann ![]() DelphiSorcery -> ![]() DelphiSpring -> ![]() VST -> ![]() Dann die Projekte erzeugen: VST === Package erzeugen C:\Users\as\Projekte\DSharp\vst\Packages\Delphi XE\VirtualTreesR.dproj Bibliothekspfad hinzufügen: C:\Users\as\Projekte\DSharp\vst\Common Packages installieren C:\Users\as\Projekte\DSharp\vst\Packages\Delphi XE\VirtualTreesD.dproj DelphiSpring ============ Package erzeugen C:\Users\as\Projekte\DSharp\delphispring\Packages\ DelphiXE\Spring.System.dproj [DCC Warnung] Spring.System.dpk(50): W1006 Unit 'Spring.Reflection.ValueExpression' ist veraltet Package erzeugen C:\Users\as\Projekte\DSharp\delphispring\Packages\ DelphiXE\Spring.Core.dproj [DCC Warnung] Spring.Core.dpk(35): W1007 Unit 'Spring.Configuration.ConfigurationProperty' ist experimentell [DCC Warnung] Spring.Core.dpk(36): W1007 Unit 'Spring.Configuration.Node' ist experimentell [DCC Warnung] Spring.Core.dpk(37): W1007 Unit 'Spring.Configuration' ist experimentell [DCC Warnung] Spring.Core.dpk(39): W1007 Unit 'Spring.Configuration.Sources' ist experimentell [DCC Warnung] Spring.Logging.LoggerManager.pas(39): W1007 Unit 'Spring.Configuration' ist experimentell Ausführen C:\Users\as\Projekte\DSharp\delphispring\Tests\Spr ing.Tests.dproj [DCC Warnung] Spring.Tests.Reflection.pas(108): W1006 Unit 'Spring.Reflection.ValueExpression' ist veraltet [DCC Warnung] Spring.Tests.Configuration.pas(32): W1007 Unit 'Spring.Configuration' ist experimentell [DCC Warnung] Spring.Tests.Configuration.pas(53): W1007 Unit 'Spring.Configuration.Node' ist experimentell [DCC Warnung] Spring.Tests.Configuration.pas(54): W1007 Unit 'Spring.Configuration.Sources' ist experimentell [DCC Warnung] Spring.Tests.Configuration.pas(55): W1007 Unit 'Spring.Configuration.ConfigurationProperty' ist experimentell [DCC Warnung] Spring.Tests.Logging.pas(7): W1007 Unit 'Spring.Configuration' ist experimentell [DCC Warnung] Spring.Tests.Logging.pas(8): W1007 Unit 'Spring.Configuration.Sources' ist experimentell [DCC Warnung] Spring.Logging.LoggerManager.pas(39): W1007 Unit 'Spring.Configuration' ist experimentell DelphiSorcery ============= Alle Packages erzeugen Package installieren C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclDataBindings.dproj C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclDataBindingsVCL.dproj C:\Users\as\Projekte\DSharp\delphisorcery\Packages \DelphiXE\dclTreeViewPresenter.dproj => Sampels\MVVM\Calculator Bibliothekspfad hinzufügen: C:\Users\as\Projekte\DSharp\delphispring\Library\D elphiXE\Debug ... OK => Sampels\MVVM\Explorer Bibliothekspfad hinzufügen: C:\Users\as\Projekte\DSharp\delphisorcery\Samples\ MVVM\Calculator\Debug\Win32 ... [DCC Fataler Fehler] DSharp.Core.RegularExpressions.pas(93): F2051 Unit DSharp.Aspects.Weaver wurde mit einer unterschiedlichen Version von DSharp.Core.Reflection.TRttiTypeHelper.GetAttribut esOfType compiliert => Sampels\MVVM\ContactManager Bibliothekspfad hinzufügen: C:\Users\as\Projekte\DSharp\vst\Source Fazit: ~~~~~~ Grundsätzlich hat die Installation so funktioniert. Besonders hat mich (natürlich) das MVVM interessiert. Die Beispiele muss ich mir noch in Ruhe anschauen. Der Explorer ließ sich jedoch nicht erzeugen. Auf den ersten Blick konnte ich nicht nachvollziehen, wieviel Arbeit das Framework einem wirklich erspart - wie es also für das Erstellen eines neuen Projektes letztlich eingesetzt wird. Hat man wirklich deutlich weniger Arbeit dadurch? Soweit mein erster Eindruck. Mir fehlt noch etwas der Zugang. Ich muss mir dafür nochmal die Zeit nehmen. Ein Video (notfalls auch in englisch) wäre m.E. ganz nett... ;-) |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Ich hab gestern einen neuen
![]() Eine Sache noch - um Verwirrung zu vermeiden: die Library heißt DSharp, mein Blog Delphi Sorcery. Zum Zeitpunkt als ich das repository auf google code angelegt habe, gab es den Namen DSharp für die Lib noch nicht, daher hab ich es unter dem Namen des Blogs veröffentlicht - leider kann man nach wie vor nicht einfach das Projekt umbenennen oder einfach umziehen; daher lass ich es erstmal so. |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Gerade mal den Blog-Post gelesen:
Vielleicht liegt es einfach dran, dass Montag ist, aber würde es nicht langen ein ViewModel-Interface im Framework mit zu liefern, anstatt jedes Mal ein eigenes leeres Interface zu deklarieren? Für den Fall, dass man ein nicht-leeres Interface verwenden möchte, kann man dann ja immernoch ein eigenes nehmen, oder? PS: Ich bezieh mich da gerade auf das ICalculatorViewModel aus dem Beispiel. |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Und was soll der DI Container dann zurückliefern, wenn ein Resolve<IViewModel> aufgerufen wird, welches von 2 komplett unterschiedlichen ViewModel Klassen implementiert wurde, weil man kein eigenes Interface (leer oder nicht) deklariert hat?
|
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
:wall:
Ich sollte Montags einfach nichts posten :D Naja, also streng genommen könnte man über alle Implementierungen des Interfaces iterieren und über die Namens-Konventionen gehen. Disclaimer: Es ist immernoch Montag. |
AW: DSharp - Data bindings, MVVM und mehr für Delphi 2010 und höher
Möglich wäre das, aber das würde einen größeren Eingriff in die Funktionsweise des DI Containers erfordern. Und das nur, um sich nen 3-Zeiler zu sparen für den Fall, dass man ebend in dem Interface für das ViewModel keine Methoden und/oder Eigenschaften hat, halte ich für keinen guten Weg.
Ich denke, deine Frage zielte auf etwas anderes: Es spricht nichts dagegen, komplett auf das Interface zu verzichten in diesem simplen Fall. Im Calculator Beispiel würde das dann bedeuten, du schreibst einfach
Delphi-Quellcode:
Die Registrierung der Klasse passiert in diesem Fall durch das [InheritedExport] auf TViewModelBase.
Application.Start<TCalculatorViewModel>;
Wenn du dir das ContactManager Sample anschaust, wirst du aber sehen, warum das Interface in weniger trivialen Anwendungen fast unverzichtbar ist. Dort hast du nämlich die Kontaktübersicht, welche als Abhängigkeit die Kontaktdetails hat (weil es sie ja aufrufen muss). Wäre dort kein Interface für die Details vorhanden, hättest du eine Abhängigkeit dieser 2 Models. Mit dem Interface kannst du einfach das DetailViewModel ausmocken und die Übersicht testen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:41 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz