Changed documentation regarding extension properties api

[Jolanrensen]

Fixes #635
more explicit explanation of what happens in between cell calls in the extension properties api in notebooks

[AndreiKingsley]

It seems to me that for very beginning users it may not be completely clear yet. I would add a DataFrame head (as table md) so the user would see its columns, then show

1. that now df has properties with these names
2. show some simple example (select for example) with String API and say that now it can be rewritten like this with Column selection DSL.

[AndreiKingsley]

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 code df.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.

[Jolanrensen]

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 code df.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.

[AndreiKingsley]

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.

[Jolanrensen]

@AndreiKingsley so more like here? https://kotlinlang.org/docs/data-analysis-work-with-data-sources.html#display-data

[AndreiKingsley]

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.