What was the inspiration for the ztm.topicmaps API?
TMAPI and a later desire for a more “pythonic” feel.
ZTM 2.0 was based on the Java based TMAPI 1.0, with minor allowances for Python. Over time the codebase pythonified, using more Python/Zope idioms.
When we started ztm.topicmaps (ZTM3) we couldn’t do anything too radical, so we kept what we felt worked and removed some longstanding annoyances and performance issues. The API was modified to feel a lot more pythonic.
We still consider the API to granular, making some optimizations much harder, but this is to a large degree alleviated by the use of adaption and domain APIs.
Why do some methods on ztm.topicmaps.interfaces.ITopic have som many parameters?
Not asked that often, but should be pre-answered anyway. :-)
Methods that take many parameters are hard to remember, hard to debug, and has a complex implementation. Generally they are considered bad design, yet we still have plenty of them in ztm.topicmaps.
The ztm.topicmaps API evolved over many years. We found that a straight up TMAPI-ish implementation resulted in a lot of boilerplate code in views to prepare things for rendering. This was due to the request-based nature of ZTM applications.
The amount of boilerplate has fallen considerably, leading to what we feel is more succinct code.
Why can topic references be any of subject reference, serial number and object reference?
In ZTM2 the API mostly took object references. This lead to a proliferation of topic lookups just before doing whatever was actually being searched for or modified. Typically a single createAssociation might require as much as 5 lines of topic lookups. This tended to obscure the intention of the code.