Closed Jolanrensen closed 1 month ago
The paragraph assumes that the user 1) knows the "titanic" columns 2) has learned the String/CA API well. I think this is not a good approach. Instead of adding some explanations of the working mechanism, we should let the user understand what extension properties bring (and show that they are generated from columns). Imagine you make a notebook that you show to a newbie in DataFrame - first you load a table and display it, look at it, look at its columns. Then you can show that your
df
has extensional properties (i.e. write the codedf.age
and show what it will output). Then you show an example with String/Accessors API, and then rewrite it with EP API, and say that's how great it is.
While that's a fantastic approach for, say, a demo, I'm not sure we can convey it like that on a static website. It might take some actual screenshots to show how generated accessors will look. Not a bad idea though, I'll think about it.
I don't see the problem, to be honest. Originally all Kandy guides were notebooks, but we moved them to md paragraphs. No dynamics here, just add some code blocks + static outputs.
@AndreiKingsley so more like here? https://kotlinlang.org/docs/data-analysis-work-with-data-sources.html#display-data
In this case there is no need to make a guide, a short chain explanation is enough: there was a dataframe with such columns -> such EPs were generated -> they can be used instead of string/accessors and have a lot of advantages.
I made it simpler, now I'm just sending the users to https://kotlin.github.io/dataframe/schemas.html which explains everything with examples and all :)
Generated sources will be updated after merging this PR. Please inspect the changes in here.
Fixes https://github.com/Kotlin/dataframe/issues/635 more explicit explanation of what happens in between cell calls in the extension properties api in notebooks