[Silverlight] Binding, oneway en dan saven

[Snake]

Hi,

Ik heb een simpel silverlight formpje, met een listbox en een een textbox.

Als je je selectie wijzigt in je listbox wordt een bepaald property van het geselecteerde item in die listbox in mijn textbox geladen via databinding:

XML:

<Grid Margin="8" Grid.Row="1" Name="myGrid" DataContext="{Binding ElementName=myListBox, Path=SelectedItem}">
            <Grid.ColumnDefinitions >
                <ColumnDefinition />
                <ColumnDefinition />
            </Grid.ColumnDefinitions>
            <TextBox Margin="8" Text="{Binding Path=Name, Mode=OneWay}" TextWrapping="Wrap" VerticalAlignment="Center"/>
            <StackPanel Margin="8" Grid.Column="1" Orientation="Vertical" HorizontalAlignment="Center" VerticalAlignment="Center">
                <Button Content="Save"  HorizontalAlignment="Center" Width="50" Margin="8" Name="buttonSave" Click="buttonSave_Click" />
                <Button Content="Cancel" HorizontalAlignment="Center" Width="50" Margin="8" Name="buttonCancel"/>
            </StackPanel>
        </Grid>

Nu wordt mijn change in mijn textbox NIET doorgevoerd naar mijn selected object (OneWay binding).

Maar als ik op Save duw moeten mijn changes WEL worden doorgevoerd naar het onderliggend object.

Ik zit al een paar uur te zoeken op een manier om dat automatisch te doen, ipv handmatig die value uit die textbox uit te lezen en zo mijn geselecteerd object updaten.

(hier is het maar 1 textbox, maar in de applicatie zijn het +20), niet echt ideaal voor maintainability.

Overal op Google implementeren ze die savebutton als handmatig, alle properties uitlezen en dan updaten in het onderliggend object.

Heeft hier iemand een tip voor, en misschien belangrijker: is het uberhaupt mogelijk op de manier die ik wil?

[bigbeng]

Je kunt dit bereiken door met een ModelViewViewModel principe te werken. In plaats van direct naar een onderliggend object te schrijven, gebruik je een viewmodel om de interactie tussen je view en model te laten controleren. Zie bijvoorbeeld hier:
http://msdn.microsoft.com/en-us/magazine/dd458800.aspx

Je houdt dan de state bij in je viewmodel en op het moment dat je op de save knop duwt persist je die state naar je model. Kost even wat opzetwerk, maar zorgt voor heel voorspelbare code.

[SaphuA]

.

[ Voor 105% gewijzigd door SaphuA op 01-02-2022 17:05 ]

[Niemand_Anders]

Kijk eens naar het Caliburn (codeplex) of CSLA framework.

Op het moment dat je naar de edit mode gaat van je formulier zet je je entity in de edit modus door middel van {entity}.BeginEdit(); Met {entity}.EndEdit() worden dan de wijzigen opgeslagen en middels {entity}.CancelEdit() wordt de state van de entity hersteld zoals deze was voor de BeginEdit() call.

Op die manier kun je gewoon two-way bindings gebruiken zonder dat wijzigen direct overal zichtbaar. Zowel Caliburn als CSLA ondersteunen multilevel edit niveau's. Ofwel je kunt genest BeginEdit() aanroepen.

Ook one-to-many en many-to-many relaties (zoals vak voorkomt bij gebruik van ORM frameworks) worden ondersteund. Zodra je BeginEdit() aanroept wordt door het framework ook BeginEdit aangeroepen op de gerelateerde objecten.

C#:

Customer cust = new Customer();
cust.BeginEdit();
cust.Name= "S. Shopper";
cust.Address.Zipcode = "3033BE";  // <-- ook de Address entity wordt in de edit modus gezet.
cust.EndEdit(); 

[Snake]

bigbeng schreef op donderdag 22 oktober 2009 @ 10:38:
Je kunt dit bereiken door met een ModelViewViewModel principe te werken. In plaats van direct naar een onderliggend object te schrijven, gebruik je een viewmodel om de interactie tussen je view en model te laten controleren. Zie bijvoorbeeld hier:
http://msdn.microsoft.com/en-us/magazine/dd458800.aspx

Je houdt dan de state bij in je viewmodel en op het moment dat je op de save knop duwt persist je die state naar je model. Kost even wat opzetwerk, maar zorgt voor heel voorspelbare code.

Maar dan ben je nog steeds bezig met handmatig die properties te updaten.

Ofwel met Reflection.

[bigbeng]

Snake schreef op donderdag 22 oktober 2009 @ 10:49:
[...]

Maar dan ben je nog steeds bezig met handmatig die properties te updaten.

Ofwel met Reflection.

Klopt! Dat is de prijs die je betaald door het binding object te gebruiken voor meerdere doelen, namelijk als datamodel en als intermediate state. Je gaat nu dus een gevecht aan met een framework wat niet gebouwd is met dat doel. Hoeveel van dit soort uitzonderingen zitten er in de applicatie die je aan het bouwen bent en hoeveel pijn (als in financiele pijn) doet het als je 1 veld (gebaseerd op jouw voorbeeld) handmatig moet updaten?

Als je met Silverlight 3 aan de slag bent kun je eens kijken naar UpdateSourceTrigger, misschien dat je daarmee meer controle kunt pakken over het updaten van je bindings. Tenslotte: Ik neem aan dat je weet dat Reflection precies datgene is wat Silverlight gebruikt om de juiste getters en setters van je bindings aan te roepen?

[ Voor 20% gewijzigd door bigbeng op 23-10-2009 04:44 ]