dm4-webclient: topicmaps.get_topicmap() is now undefined in init_3

[Malte]

Testing the 4.8.4-snapshot (which jri send the link to over the devel list), the following behavior seems to be new to me:

dm4c.add_listener("init_3", function() {
    topicmaps = dm4c.get_plugin("de.deepamehta.topicmaps")
    console.log("Topicmaps Plugin getTopicmap: ", topicmaps.get_topicmap())
})

Prints out in the developer console:

Selecting topicmap 2143 (ID obtained from browser URL), selected topic: 4015
Topicmaps Plugin getTopicmap: undefined

Is this an anticipated result? It breaks my stableviews plugin webclient integration.

[Malte]

Update: I got this working as i do not necessarily need the ID of the selected topicmap in "init_3". And later at runtime (when the use actually clicks my link) the call "topicmaps.get_topicmap().getId()" works fine.

Nonetheless it is curious that internally (to the topicmaps plugin?) the selected topicmap is known (see console output above, 1st linie) but not if i request it from my webclient plugi (2nd line). So this might actually be a new issue.

[jri]

Replying to Malte:

Update: I got this working as i do not necessarily need the ID of the selected topicmap in "init_3". And later at runtime (when the use actually clicks my link) the call "topicmaps.get_topicmap().getId()" works fine.

Oh, you're right!
This is actually another BREAKING CHANGE not yet documented!
The change has to do with 4.8.4's stale cookie fix (#1017).

In 4.8.3 the initially displayed topicmap is guaranteed to be available to other plugins at init_3() time.
In 4.8.4 it is not.
The current 4.8.4-SNAPSHOT provides no way to get the initially displayed topicmap at init time.
A solution would be for the Webclient to introduce another init level -- init_4()! -- BUT ... puuh ... all these init levels :-(
I tend to not do that in the 4.8.4 release.

Good to know your plugin doesn't strictly rely on that :-)

Nonetheless it is curious that internally (to the topicmaps plugin?) the selected topicmap is known (see console output above, 1st linie) but not if i request it from my webclient plugi (2nd line). So this might actually be a new issue.

In conjunction with #1017 initialization of the Topicmaps plugin is now a hairy thing. It determines a topicmap ID (note: just an ID, not an actual Topicmap object) at init_1() time. This is what you see on the console. BUT: it might revert that decision at init_3() time! This happens when stale cookies are detected by the Workspaces plugin (resp. the topicmap ID obtained from the browser URL is invalid in any way). In that case you'll see a WARNING on the console.

For more details see also ticket:1017#comment:4 and the detailed comments in the client-side init code of both, the Topicmaps, and the Workspaces plugin.

Thank you very much for feedback!
:-)

[jri]

BTW: all that hassling with the Webclient's init levels feels like ancient System V run levels. (That's why systemd was invented, right?). A better Webclient design would make use of Promises.