[Isomorphic]

That's sort of close.

No call should force early initialisation / initialization

Initialisation is done via fetchData() or draw().

Anything that causes drawing or fetching initializes a widget. For example, using addMember() to add a widget to a Layout that is drawn immediately draws the widget.

Some other calls (e.g. the set*State calls) depend on setFields() and therefore must come after setFields().

This is not really related to properties that can only be set before draw/initialization. It's just a senseless order of calls. To make an analogy, if you are using a library that makes network calls, you can't tell it to connect before you give it the target address.

[Blama]

Hi Isomorphic,

That's sort of close.
Anything that causes drawing or fetching initializes a widget. For example, using addMember() to add a widget to a Layout that is drawn immediately draws the widget.

That's the information I was looking for, thanks.

That's sort of close.
This is not really related to properties that can only be set before draw/initialization. It's just a senseless order of calls. To make an analogy, if you are using a library that makes network calls, you can't tell it to connect before you give it the target address.

I understand that analogy, but to be honest, it would work for setSort() before setFields() as well:

1. "no fields so far, but when the ListGrid initializes some time in the future, please sort by field A ASC and field B DESC" vs.
2. "no fields so far, but when the ListGrid initializes some time in the future, please use these settings for the viewstate"

I understand that this might be an edge case, but still I think it should be somehow documented.

Therefore it would be really helpful to have an how-to-ListGrid the the one above in the Quick Start Guide or the general ListGrid docs, if you don't what to clutter the QSG with too much detail information.
I also think I forgot one call in the list: setDataSource():

1. No call should force early initialisation / early initialization
2. Initialisation is done via fetchData() or draw() or anything that causes drawing or fetching (e.g. using addMember() to add a widget to a Layout that is drawn immediately draws the widget)
3. setDataSource() should be called at the very beginning when configuring a ListGrid (it even has a constructor for it)
4. Some calls are only possible before initialisation. These are marked with "Throws: java.lang.IllegalStateException - this property cannot be changed after the component has been created" in the docs
5. Some other calls (e.g. the set*State calls) depend on setFields() and therefore must come after setFields()

Something similar should be true for DynamicForms as well.

Best regards,
Blama

[Isomorphic]

Sorry, we don't agree.

We did happen to make setSort() work regardless of order, but this has no impact on someone who is already using the call order that is obvious, because it works either way.

Again we would make the analogy to trying to connect before an address is provided. Documenting self-evident dependencies like this would be pedantic, would worsen the docs with clutter, and waste time better spent on doc improvements that would help people.

That all said, if *actual bugs* are discovered where a setter forces initialization when it should not, or someone points out a dependency where multiple people find it non-obvious, we would of course make changes.

[Blama]

Hi Isomorphic,

OK, understood. Early initialization would be a bug, calls that have to come before initialization are already marked with IllegalStateException and other dependencies are very seldom.
So far, the set*State() are the only ones affected with their dependency to setFields(), right? If I find another, I'll post here.

Best regards,
Blama