Wie kann ich einen hidden value an ListBox Item anhängen ähnlich der id als "hidden" im HTML?
Moin,
kann man irgendwie eine Art Hidden Value an die ListBox Elemente anhängen, wo ich eine ID hinterlegen kann, ähnlich wie im HTML <input name="xyz" value="test" hidden="1234">?
Ich fülle die Liste mit Personen aus einer Datenbank. Die Liste zeigt mir Vorname und Nachname an. Nun gibt es zwei Hans Müller. Will jetzt wissen, welchen von beiden ich auswähle. Am besten wäre es, wenn ich die ID aus der DB an jedes Element übergeben könnte.
Geht das irgendwie?
Geht das irgendwie?
Diese Frage kann man prinzipiell mit "Ja" beantworten.
Und ein "Hidden Item" ist auch kein Thema, mach eben die Höhe per Style auf 0.
Aber was Du schreibst, klingt, als würdest Du alle drei Schichten ( [Artikel] Drei-Schichten-Architektur ) durcheinander werfen?
Außerdem solltest Du bei WPF nach MVVM ( [Artikel] MVVM und DataBinding ) arbeiten, das ermöglicht dir, eine sehr einfache Trennung zwischen UI und einer ViewModel-Klasse, wo Du dann dann und lassen kannst, was Du willst.
Ich würde für die Person neben dem Model noch ein ViewModel mit allen Anzeige-Daten anlegen und dann die ViewModels an die ListBox übergeben. Das ViewModel kann dann auch zusätzlich eine Property wie "IsSelected" haben, über die Du dir dann merken kannst, welcher Eintrag ausgewählt wurde.
Aber vergiss nicht: Auch in dem ViewModel hat keine Datenbank-Operation etwas verloren.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
In [Artikel] MVVM und DataBinding gibt es auch Beispiel-Code und ein Beispiel-Projekt dazu.
Weeks of programming can save you hours of planning
Drei-Schichten-Architektur: Schreibe gerade alles drauf um.
MVVM: Ist drin. Für Listen nutze ich es aber nicht, da ich die Listen nicht über MVVM zum Laufen bekomme. Im Artikel der Punk 2.4, wie befülle ich da die Liste? Muss ich für jeden Listeneintrag ein Objekt von EmployeeViewModel instanziieren? Diesen Datentyp erwartet nämlich viewModel.Employees.Add.
Du mußt nicht zwangsläufig ein ViewModel bei der ObservableCollection<T> benutzen, das kann ein beliebiger Datentyp sein (also z.B. eine eigene Klasse mit verschiedenen Eigenschaften, wo du dann eine [oder mehrere] der Eigenschaften bei der ListBox per Binding für die Anzeige angibst und alle anderen sind quasi "hidden").
Du mußt nicht zwangsläufig ein ViewModel bei der ObservableCollection<T> benutzen, das kann ein beliebiger Datentyp sein
Das ist doch ein ViewModel? 😄
Muss ich für jeden Listeneintrag ein Objekt von EmployeeViewModel instanziieren?
Ich sehe da kein Problem, pro Eintrag ein ViewModel zu erzeugen. Gut, sind ein paar Objekte mehr, aber solange das kein Performance-Problem ist, würde ich nicht weiter darüber nachdenken.
Außerdem hast Du später den Vorteil, dass Du das ViewModel-Objekt mit anderen View-Daten behalten und nur das Model austauschen kannst (PropertyChanged nicht vergessen), das erspart 1. aufwändiges Neu-Aufbauen der Controls pro Item (ich hatte deshalb schon mehrere Minuten Ladezeit, die ich reduzieren musste) und 2. hast Du so eine billig Art "Speicherstand", der auch nach dem Neuladen nicht verloren geht.
Alternativ kannst Du aber auch nur die Models rein stecken und neben die Liste eine "SelectedItem"-Property anlegen. Die kannst Du dann binden und weißt, welches Item gerade ausgewählt ist.
Und die "hidden" Items fügst Du einfach nicht der Liste hinzu.
Streng genommen wäre das kein reines MVVM, das erlaubt keine Models auf View-Ebene, allerdings ist das vermutlich auch eine Frage der Interpretation und des Geschmacks.
MMn. ist beides eine Option, gerade bei kleinen Projekten lohnt es nicht immer, für alles ein eigenes ViewModel zu bauen. Auf der anderen Seite musste ich aber schon oft genug ein ViewModel nachrüsten, weil ich nur so die Möglichkeit habe, zusätzliche View-Daten pro Item zu haben.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.
Ok, es klapp. Nicht so ganz, wie im Beispiel mit zwei ViewModels, aber mit einem geht das. Auf jeden Fall hat es mein Hidden Value Problem gelöst, da ich vom SelectedItem das entsprechende Objekt zurückbekomme und nicht nur einen Listenindex. 😃
eine Frage der Interpretation und des Geschmacks
Nee. Nur eine Frage der Funktionalität. Werden die Daten geändert und muß die UI über eine Änderung informiert werden, um die Bindings zu aktualisieren, braucht es ein ViewModel mit INotifyPropertyChange. Ansonsten nicht.
Weeks of programming can save you hours of planning
Man kann MVVM aber auch so interpretieren, dass Models gar nicht an die View gebunden werden dürfen.
Das meine ich mit "Interpretation und Geschmack".
Ob das jetzt sinnvoll ist, muss jeder selbst entscheiden.
NuGet Packages im Code auslesen
lock Alternative für async/await
Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.