FSharp.Data
FSharp.Data copied to clipboard
fsprojects
Support data-binding
Implement ICustomTypeDescriptor in type providers to support data-binding. I hope that should be sufficient.
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?
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.
Actually, this would be much more useful in the Json provider than in the Csv provider.
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.
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
Ah crap, WPF has ICustomTypeDescriptor, Silverlight has ICustomTypeProvider, and Windows Store has neither, so this won't work in the portable version
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!
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...
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).
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?
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.
Yes, JsonProvider still doesn't work with WPF binding and other similar reflection based systems
@isaacabraham want to take to shot into changing Csv provider into a generated tp? It would play nicer with your Azure tp
Please keep erasure the default, eg. make generative an optional parameter or different provider. Generative providers add significant complexity in a number of ways.
@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...)
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?
@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?
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
Wow, any updates on this one? it would be nice to see actual types and properties from C# when referencing an F# library using JsonProvider or others in FSharp.Data :) also making it an optional parameter would be awesome. Sometimes this is a limit for integrating F# types provider with C#, so it might be worth it for "enterprise adopters" to have actual generated types in the final assembly, so that they can use them from C#.
