Skip to content

Loading…

Support data-binding #134

Open
tpetricek opened this Issue · 18 comments

5 participants

@tpetricek
F# Compiler and Components (Open Edition) member

Implement ICustomTypeDescriptor in type providers to support data-binding. I hope that should be sufficient.

@tpetricek
F# Compiler and Components (Open Edition) member

This makes me think - will we have to represent rows (in CSV provider) using our own Row type rather than using tuples, so that the row type can implement the interface too?

@ovatsus
F# Compiler and Components (Open Edition) member

Usually you databind to an intermediate viewmodel, as rarely the data is right in the format you want to display it in, but I do agree that when prototyping, being able to just databind to a type provider would be nice. The tuple gives us a couple of nice properties, but we can keep it, wraping it in a Row type, and still being able to implement ICustomTypeDescriptor, it's perfectly doable.

@ovatsus
F# Compiler and Components (Open Edition) member

Actually, this would be much more useful in the Json provider than in the Csv provider.

@tpetricek
F# Compiler and Components (Open Edition) member

I do agree that this is more important for the other providers than CSV. But having that for CSV would enable some nice scenarios too.

@ovatsus
F# Compiler and Components (Open Edition) member

Yes, CSV is actually the easier one to implement. I was just trying out prototyping it for the JsonProvider, and it's a bit more tricky

@ovatsus
F# Compiler and Components (Open Edition) member

Ah crap, WPF has ICustomTypeDescriptor, Silverlight has ICustomTypeProvider, and Windows Store has neither, so this won't work in the portable version

@tpetricek
F# Compiler and Components (Open Edition) member

I was just trying out prototyping it for the JsonProvider, and it's a bit more tricky

Can you elaborate a bit? What are the tricky things with the JsonProvider?

WPF has ICustomTypeDescriptor, Silverlight has ICustomTypeProvider

Oh, great... that sucks!

@ovatsus
F# Compiler and Components (Open Edition) member

It's just passing all the information hierarchically from compile time to runtime, so we don't have to implement everything twice. Maybe it would be best just to make the JsonValue and CsvFile play nicer with data binding, similar to what can be already done today with XElement, and leave this out of the type providers. You do loose most of the static typing benefits with data binding anyway...

@tpetricek
F# Compiler and Components (Open Edition) member

Yes, I think this could be done just by implementing the interface in the runtime classes (not touching the design time code).

(That's why I thought supporting it for CSV would be tricky as we do not control the runtime type).

@ovatsus
F# Compiler and Components (Open Edition) member

Actually, the CSV is the most C# friendly right now. In code you get Item1 and Item2 with the right types, and can use {Binding Item1} and {Binding Item2}. It's not ideal, but at least it's possible to use.
Json is the worst one, as everything is erased, and the JsonValue DU is completely unusable inside a data binding.
What if we changed the json provider to use generated types instead of erased ones? What would be the drawbacks of that?

@WallaceKelly

I just tried to use a JsonProvider-created type in a WPF control with data binding. It did not work, as implied by the above discussion. Is this the latest on the topic? If so, I must re-create the JsonProvider-created type and copy all the data over. That seems to defeat the purpose of having a JsonProvider -- at least for a WPF app. If I must define my own type, I might as well just use a JSON deserializer.

@ovatsus
F# Compiler and Components (Open Edition) member

Yes, JsonProvider still doesn't work with WPF binding and other similar reflection based systems

@ovatsus
F# Compiler and Components (Open Edition) member

@isaacabraham want to take to shot into changing Csv provider into a generated tp? It would play nicer with your Azure tp

@dsyme

Please keep erasure the default, eg. make generative an optional parameter or different provider. Generative providers add significant complexity in a number of ways.

@tpetricek
F# Compiler and Components (Open Edition) member

@dsyme Can you elaborate in what ways do they add complexity (e.g. performance, potential for bugs, difficulty with assembly loading)? (Because the number of types in case of XML, JSON and CSV provider would probably be quite manageable...)

@ovatsus
F# Compiler and Components (Open Edition) member

I like the idea of erased type providers more than generative ones, but unfortunately:

  • They don't work with data-binding by default. You can try to workaround it using ICustomTypeDescriptor, but it only works in WPF, and not Xamarin, Silverlight, Windows Phone, or Windows Store
  • They don't work with other libraries that use reflection to get property names like Deedle and the Azure TP
  • They cause problems when they are used trough libraries and not directly in apps, because the TP will be re-evaluated. This causes problem in FSharp.Data.Toolbox and the like

Generative types have these disadvantages:

  • Have to generate the full tree ahead of time, so they might be slower at compile time
  • For the same reason create larger binaries
  • I have the gut feeling it will be harder to debug the output of the TP, but I'm just guessing

I haven't implemented any generative TP yet, so I'm not sure about added complexities in implementing them, but I'm guessing it should be about the same as erased ones

What am I missing?

@isaacabraham

@ovatsus happy to have a look into this - although might a simpler (hackier?) option of just making the set of key/value pairs available on the erased type so that you can at least programmatically get to the values at runtime?

@ovatsus
F# Compiler and Components (Open Edition) member

I'd prefer the less hacky version. It will probably take the same time to implement and then we can share that approach more easily on the 3 providers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.