[ASP.Net/C#] Heterogene collecties in datagrid

[zoepercavia]

Probleem:

Ik heb de volgende overervingsstructuur.

Product
Product <- AtomicProduct (Atomic erft over van Product)
Product <- ComplexProduct (Complexerft over van Product)

Ik bind een ProductCollection aan een datagrid. Deze collectie kan zowel AtomicProducts als ComplexProducts bevatten (ze zijn immers beiden van het type Product). Als de collectie alleen AtomicProducts of alleen ComplexProducts bevat dan gaat het goed. Bevat de collectie echter beide dan krijg ik de volgende fout

code:

Object does not match target type. 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.Reflection.TargetException: Object does not match target type.

Het lijkt dus zo te zijn dat de datagrid het type van de items bepaalt op basis van het eerste item in de collectie. Hij komt dus eerst bv. een AtomicProduct tegen en zegt dat is het type, als hij vervolgens dan bij ComplexProduct komt dan gaat het mis omdat die niet van het type AtomicProduct is.

Das dus mooi kut, want collecties met een heterogeen subtype (maar een met een zelfde supertype) zijn erg handig.

Weet iemand hier een oplossing voor, want alle oplossingen die ik kan bedenken zijn veel minder schoon dan de huidige code (bv. benodige data eerst in een datatable zetten en die binden ipv de objectcollectie gebruiken). Ik kan bijvoorbeeld niks vinden om het type van de items in de datagrid te forceren.

[EfBe]

Kan niet. Een grid haalt de property descriptors op van het 1e object in de collection. Als een volgend object niet van datzelfde type is, krijgje die exception.

Is ook wel logisch, wat moet hij tonen in de cells in columns voor properties die niet in het 1e object zitten maar wel in het volgende? Wat als de collection 500 objects bevat, moet hij alle objects reflecten, alle columns verzamelen etc.?

[zoepercavia]

Hmm.. ik snap je punt. Het is alleen wel jammer, omdat ik nu een stukje transparantie verlies. Of is er misschien iets mis met heterogene collecties (ik vind het zelf erg handig)?

[Verwijderd]

Misschien een interface IProduct maken en dan AtomicProduct en ComplexProduct die laten implementeren. Gewoon de properties die in de interface staan in een andere vorm teruggeven.
Dan in die collection IProduct'en steken.

is maar een snelle hersenspinsel

[gorgi_19]

Wat je kan doen is met templatecolumns gaan werken, dan kan je het probleem ook omzeilen.

[EfBe]

gorgi_19 schreef op 21 januari 2004 @ 21:41:
Wat je kan doen is met templatecolumns gaan werken, dan kan je het probleem ook omzeilen.

Volgens mij werkt het dan ook niet, want je moet dan opgeven welk property je mee bind en hij gaat altijd alleen het 1e object reflecten.

[gorgi_19]

EfBe schreef op 21 januari 2004 @ 21:49:
[...]


Volgens mij werkt het dan ook niet, want je moet dan opgeven welk property je mee bind en hij gaat altijd alleen het 1e object reflecten.

* gorgi_19 was misschien een klein beetje onduidelijk...

Een iets duidelijker voorbeeld..

Visual Basic .NET:

Namespace ProSim.Controls

    Public Class LabelColumn
        Implements ITemplate

        Public Sub New()
        End Sub

        Public Sub InstantiateIn(ByVal container As Control) Implements ITemplate.InstantiateIn
            Dim l As Label = New Label()
            AddHandler l.DataBinding, AddressOf BindData
            container.Controls.Add(l)
        End Sub

        Public Sub BindData(ByVal sender As Object, ByVal e As EventArgs)

            Dim l As Label = CType(sender, Label)
            Dim container As DataGridItem = CType(l.NamingContainer, DataGridItem)
            Dim data As MyCustomObject = CType(container.DataItem, MyCustomObject)
            l.Text = data.MyProperty

        End Sub

    End Class 
End Namespace

Op deze manier forceer je het onderliggende item naar het object. Kan hij hem niet casten, dan wordt een exception gegeven.

[ Voor 4% gewijzigd door gorgi_19 op 21-01-2004 21:57 ]

[tijn]

EfBe schreef op 21 januari 2004 @ 21:49:
[...]
Volgens mij werkt het dan ook niet, want je moet dan opgeven welk property je mee bind en hij gaat altijd alleen het 1e object reflecten.

Dat weet ik niet hoor, als je van te voren de properties vastlegt die gebonden moeten worden gaatie denk ik niet voor elk object de properties reflecten, maar doelgericht GetValue() aanroepen van de opgegeven properties. Lijkt me in ieder geval het proberen waard.
Zelf heb ik o.a. voor dit soort gevallen een soort van Objectview gemaakt waar je of het Type aan mee kunt geven, of een array van columns, waarbij je bij die laatste ook nog de mogelijkheid hebt om een vriendelijke columnname mee te geven. Door creatief gebruik van ITypedList en een ICustomTypeDescriptor houd je alle (ook Winforms) controls voor de gek en kun je bizar ver gaan met databinden .

[gorgi_19]

Zelf heb ik o.a. voor dit soort gevallen een soort van Objectview gemaakt waar je of het Type aan mee kunt geven, of een array van columns, waarbij je bij die laatste ook nog de mogelijkheid hebt om een vriendelijke columnname mee te geven.

Klinkt heel interessant; ik kan me alleen heel weinig er bij voorstellen... Heb je misschien iets meer informatie over deze methodiek, een linkje oid?

[EfBe]

tijn schreef op 21 januari 2004 @ 22:13:
Dat weet ik niet hoor, als je van te voren de properties vastlegt die gebonden moeten worden gaatie denk ik niet voor elk object de properties reflecten, maar doelgericht GetValue() aanroepen van de opgegeven properties. Lijkt me in ieder geval het proberen waard.

Het zou kunnen, maar ik betwijfel of het goed gaat. Wat gebeurt er als de user een value invult in zo'n cel die niet gebonden is aan een bestaande property omdat dat object toevallig dat property niet heeft?

Zelf heb ik o.a. voor dit soort gevallen een soort van Objectview gemaakt waar je of het Type aan mee kunt geven, of een array van columns, waarbij je bij die laatste ook nog de mogelijkheid hebt om een vriendelijke columnname mee te geven. Door creatief gebruik van ITypedList en een ICustomTypeDescriptor houd je alle (ook Winforms) controls voor de gek en kun je bizar ver gaan met databinden .

Klopt, alleen nu ga je ervan uit dat iedereen ITypedList e.d. kan implementeren. Aangezien er nauwelijks documentatie bestaat voor ITypedList, is het voor veel mensen een brug te ver, maar inderdaad, met een eigen property descriptor factory kun je alles binden en ook opvangen dat een object een bepaald property niet heeft en een set actie dus niet gaat lukken, maar dat dat geen exception geeft.

[tijn]

EfBe schreef op 22 januari 2004 @ 09:26:
[...]
Het zou kunnen, maar ik betwijfel of het goed gaat. Wat gebeurt er als de user een value invult in zo'n cel die niet gebonden is aan een bestaande property omdat dat object toevallig dat property niet heeft?

Euhm ja, ik ga er voor het gemak even van uit dat je dan alleen gemeenschappelijke property's bindt .

[tijn]

gorgi_19 schreef op 21 januari 2004 @ 22:24:
[...]

Klinkt heel interessant; ik kan me alleen heel weinig er bij voorstellen... Heb je misschien iets meer informatie over deze methodiek, een linkje oid?

Het is een beetje vergelijkbaar met de datatable - dataview constructie. Met een datatable kun je niet zo veel op het gebied van fancy databinding, net als een met een collectie van 'gewone' objecten. Dat objectview ding is dus vergelijkbaar met een dataview en kan gebruikt worden om te zoeken, sorteren etc.
Deze link laat hetzelfde concept ook een beetje zien (tevens inspiratiebron).

[zoepercavia]

Bedankt voor jullie reacties.

Tijn dat ziet er op zich goed uit.

Ik los het nu op een vergelijkbare maar iets minder geavanceerde manier door eerst alle objecten uit mijn collectie met een loopje in een datatable te stoppen. Op die manier worden de properties niet dmv reflectie maar op de 'normale' manier opgevraagd en gaat het goed. Die datatable bind ik dan aan mijn grid. Het is wel extra code en minder clean, maar het werkt wel.

Het is opzich wel jammer want ik was juist zo blij dat ik de collecties van mn eigen 'geprutste' OR-mapper zonder extra code kon binden aan een datagrid.

[whoami]

tijn schreef op 22 januari 2004 @ 10:07:
[...]

Het is een beetje vergelijkbaar met de datatable - dataview constructie. Met een datatable kun je niet zo veel op het gebied van fancy databinding

offtopic:
Je bindt toch nooit met een DataTable zelf, maar altijd met een DataView?

Als je nu dit hebt

code:

myGrid.DataSource = myDataSet.Tables[0];

offtopic:
Dan wordt de default dataview van die datatable eigenlijk gebruikt voor het binden, en niet de table zelf dacht ik.

[ Voor 3% gewijzigd door whoami op 22-01-2004 10:43 ]

[tijn]

whoami schreef op 22 januari 2004 @ 10:42:
[...]


[offtopic]
Je bindt toch nooit met een DataTable zelf, maar altijd met een DataView?

Hehe, dat zou goed kunnen ja. Het is ook al weer zo lang geleden dat ik een DataTable of DataView gebruikt heb. Er staat me nog vaag iets bij dat je met Webforms ook wel eens een DataRow ipv een DataRowView als dataitem in je ItemDataBound events langs ziet komen en logischerwijs verwacht je dan dat ie de DataTable direct als datasource benadert.

[tijn]

zoepercavia schreef op 22 januari 2004 @ 10:28:
Ik los het nu op een vergelijkbare maar iets minder geavanceerde manier door eerst alle objecten uit mijn collectie met een loopje in een datatable te stoppen. Op die manier worden de properties niet dmv reflectie maar op de 'normale' manier opgevraagd en gaat het goed. Die datatable bind ik dan aan mijn grid. Het is wel extra code en minder clean, maar het werkt wel.

Het is opzich wel jammer want ik was juist zo blij dat ik de collecties van mn eigen 'geprutste' OR-mapper zonder extra code kon binden aan een datagrid.

Och, zo lang je niet voor elk grid handmatig een datatable hoeft te vullen is het ook wel een aardige oplossing hoor . Ik zal vanavond thuis es kijken of ik een gestripte versie online kan zetten (er zit nl. ook nog een kruistabel-achtige functionaliteit in om lijstjes die binnen een object zitten als kolommen weer te kunnen geven en dat is niet zo relevant).

Leuk trouwens dat je die OR-mapper noemt. Zelf ben ik de laatste tijd een beetje een OR-mapper-hoer met veel wisselende contacten . Sommigen bieden nette databinding functionaliteiten en andere juist helemaal niet. Met zo'n objectview kun je met een testapplicatie lekker alle varianten doortesten.

[EfBe]

whoami schreef op 22 januari 2004 @ 10:42:
Je bindt toch nooit met een DataTable zelf, maar altijd met een DataView?

Klopt. DataTable implementeert IListSource die wordt gebruikt voor het ophalen van een list van objects om te binden aan een control via complex databinding. De DataTable produceert dan een DataView.

[zoepercavia]

tijn schreef op 22 januari 2004 @ 12:03:
[...]
Leuk trouwens dat je die OR-mapper noemt. Zelf ben ik de laatste tijd een beetje een OR-mapper-hoer met veel wisselende contacten . Sommigen bieden nette databinding functionaliteiten en andere juist helemaal niet. Met zo'n objectview kun je met een testapplicatie lekker alle varianten doortesten.

Hmm ik vrees dat mijn OR-mapper daar niet zo goed in is Mijn collecties zijn namelijk gewoon collecties die overerven via BaseCollection. En er is dus niks bijzonders voor databinding geimplementeerd. Eigenlijk is mijn mapper dan ook een uit de hand gelopen oefening in C# (ik heb C# geleerd door die mapper te maken). Ik probeer gewoon elke keer een stukje extra te maken en kijk of ik dat werkend kan krijgen. Op dit moment ondersteun ik overerving (multitable), 1-1, 1-*, *-* en recursieve relaties en worden objecten gecached in het geheugen. Maar het is nog verre van bruikbaar voor derden.

[tijn]

zoepercavia schreef op 22 januari 2004 @ 13:43:
[...]
Hmm ik vrees dat mijn OR-mapper daar niet zo goed in is Mijn collecties zijn namelijk gewoon collecties die overerven via BaseCollection. En er is dus niks bijzonders voor databinding geimplementeerd.

Juist dan is zo'n view er overheen handig omdat je dan een hoop databinding dingen niet in je Business objecten hoeft te vrotten. Bij O/R-mappers die databinding wel goed elkaar hebben is het voordeel stukken minder.