feat(clientapi): Support lists admin endpoint

[benjamingeer]

Resolves #1507.

[tobiasschweizer]

reproducible with dasch-swiss/dsp-js-lib@5be84f7

[tobiasschweizer]

Shall I try with 948ffed?

[benjamingeer]

Sorry, I think that was a copy-and-paste error. I believe I've fixed it; I tried importing the generated code into your knora-api-js-lib branch, and the tests passed.

[tobiasschweizer]

ok, will try it now!

[tobiasschweizer]

Ok, the tests pass now.

But shouldn't ListNodeInfo have a member id?

[benjamingeer]

But shouldn't ListNodeInfo have a member id?

It got moved into StoredListNodeInfo. But I'm not sure we need that class. I'm thinking about it...

[tobiasschweizer]

Is there JSON test data for CreateChildNodeRequest?

[tobiasschweizer]

It got moved into StoredListNodeInfo. But I'm not sure we need that class. I'm thinking about it...

I just think if there is a method getList(iri: string) the IRI should be present on the response so the client knows it got the correct list.

[benjamingeer]

the IRI should be present on the response so the client knows it got the correct list.

Yes, I believe it's in the response. The question is how to structure the TypeScript classes. Do we need a class hierarchy like ListNodeInfo -> StoredListNodeInfo -> ReadListNodeInfo (in which case the TypeScript function would return a ReadListNodeInfo)? Or should there just be one class, ListNodeInfo? It depends on how the list update functionality (#1447) is going to work. I guess for now it's probably best to keep it simple and just have one class.

Is there JSON test data for CreateChildNodeRequest?

It's in the e2e tests, I'll add it.

[tobiasschweizer]

It's in the e2e tests, I'll add it.

Great, thanks!

I guess for now it's probably best to keep it simple and just have one class.

Sounds reasonable. This would mean that ListNodeInfo would get a member id or listIri and just be used for reading?

[benjamingeer]

This would mean that ListNodeInfo would get a member id or listIri and just be used for reading?

Yes, id.

I've just noticed that the generated test requests for updating lists use a mixture of anything and images. I'll sort that out after lunch.

[tobiasschweizer]

Ok, just let me know when it's ready. I have already written tests for all methods but createChildNode and they all pass, see dasch-swiss/dsp-js-lib@5c35212

[benjamingeer]

OK I think this is correct, see if it looks OK to you.

[tobiasschweizer]

I could write all the tests and they pass, so I think this looks good.

Do you need to wait for #1520, #1528, and #1447 for this PR to be merged?

[benjamingeer]

Do you need to wait for #1520, #1528, and #1447 for this PR to be merged?

No, actually, since I found out at the last dev meeting that the existing functionality should still work after #1447, and the other issues will be resolved later, I think we can merge this now.

[tobiasschweizer]

I think if dasch-swiss/dsp-js-lib#128 works for @lrosenth, this PR is good to go.

[benjamingeer]

@tobiasschweizer Since you've merged dasch-swiss/dsp-js-lib#128, does that mean I can merge this PR?

[tobiasschweizer]

I still have a question that might be relevant for this PR: dasch-swiss/dsp-js-lib#129 (comment)

[tobiasschweizer]

Ok, thanks for this PR. We will figure out the details for caches later.

[daschbot]

This pull request has been mentioned on Discuss DaSCH. There might be relevant details there:

https://discuss.dasch.swiss/t/knora-v12-0-0-released/139/1