@thomasnield There is something weird in one of the examples:

@User uploaded a file: Untitled

Seems like a comment got stuck in the middle of the code example 🙂

Oh, oops.

I'll fix it when I get back, but you're welcome to remove it if you like.

I'm not quite sure how it's supposed to be, maybe it was supposed to be added afterwards? Probably better if you take a look when you have the time. I'll add some more stuff tonight, so remember to pull first 🙂

Okay will do

@edvin Did you every write about the

ListCellFragment

? I saw your comment in the archives and was wondering if this feature was documented?

I am about to put a custom cell in my

ListView

and was wondering is this is something I might want to use...

@jchildress I didn't but I will try to add it today 🙂

Looking for a place to put it now.

@edvin No problem I found an example you had posted back in July that I think is going to work for me.

@jchildress OK, great! Do you have a link or could you post it here? Maybe I can reuse some of it.

-.kt

I am using a

CheckBoxListCell

instead...

OK

@thomasnield I'm looking at

Components.md

about ListView and I see some outdated syntax:

@User uploaded a file: Untitled

@thomasnield Is this deliberate because you introduce builders later?

Using new syntax the above would be:

@User uploaded a file: Untitled

If that was your intention, I wonder if that's too "bare bones". I think we should hit the builder syntax as soon as possible.

Even if we don't talk about the builder syntax until later, we probably shouldn't show syntax that will (should) never be used in an app.

@thomasnield If you agree, I can rewrite the examples 🙂

There is some info about using the

with(root)

syntax and how it streamlines UI code. After the

override val root = builder

syntax, I think that's probably the only way to go really.

This was deliberate. It shows the traditional way to do it and then transitions into abstracting it all away with builders. Builders might look too alien and mysterious if introduced right away. But we can change that if you like. What do the rest of y'all think?

Looking at that code and comparing it to the builder syntax I think it is easier to understand what's going on with the builders actually. I think any programmer will see that we're building a hierarchy of nodes. Maybe I could try to rewrite it, but keep information and techniques about both ways of doing it?

There's a lot of good information in there and I don't want it to get lost, but I think it would be a mistake to introduce too many examples with "non-optimal" syntax.

@edvin @thomasnield I agree that getting to the "correct syntax" sooner than later is probably good - especially since people primarily use the documentation as a resource "to do" something. That said, the builder syntax is simple once you grok what's going on. There have been questions asked more than once that came down to people not understanding what the builder is doing under the covers (i.e. implicitly adding a node to it's parent) so a deeper explanation (even if in the appendix) might be helpful.

Okay. Let's change it then. The second chapter breaks down what is going on with builders anyway, but we can change it to the better syntax in the first chapter. I can do it unless someone beats me. Had a weird two days.