Enhancement
Slashed service calls
Issue description
A service call by an URL can have different "notations". In the simplest case a service is called by appending a list of parameters in the form of a standard URL query string. In addtion there is currently keyword routings which take a slashed appendix . In order to create a blog like structure where there is a base prefix like '/blog/' or '/article/' followed by a readable title, it is necessary to add new functionality to the Topincs URL processing.
Developer comments
The [https://www.topincs.com/manual, Topincs manual] currently uses an imature emulation of that. It has the downside that for each article a specific service must be created, of which all are identical in code apart from the id of the article. The actual text of the article is already held in the topic map, in occurrences to be be exact. This was not like this from the beginning. Initially, the individual services held the text in representational HTML component of the service. This issue is now one more step to make the management of texts easier in Topincs, after all it is a database and not a content management system.
The general idea is the following: in a service a single topic parameter is marked with a boolean occurrence type. No good name for this comes to mind right now, but let's go with *slashed*. This will cause Topincs to resolve the string after the slash (stopping at question mark) to a topic and if successful bind that to the parameter marked. This results in an ordinary URL for a service call which is then just processed as usual.
Example:
[%/blog/propertygraphs_topicmaps
/blog/123
/blog?article=123%]
The topic 123 must have the subject identifier %propertygraphs_topicmaps%.
Another example:
[%/manual/topicmaps
/manual?article=456%]
The topic 456 must have the subject identifier %topicmaps%.
For now this should only apply to GET calls.
This would work just as well with more than one slashed parameters and there is no need for marking the parameters. If a service call is detected, the remaining segments of the path are used as arguments for the parameters of the service, strictly in order. This will work very well, as long as there every parameter gets assigned no more than 1 parameter.
Example with multiple arguments passed this way:
[%/status/2025/37
/status?year=2025&week37%]
|
Work sessions3
| Start |
2025-09-12T21:00:00
|
| End |
2025-09-12T22:26:49
|
| Participant |
Robert Cerny
|
| Start |
2025-09-13T11:37:58
|
| End |
2025-09-13T14:00:06
|
| Participant |
Robert Cerny
|
| Start |
2025-09-14T09:41:08
|
| End |
2025-09-14T12:35:35
|
| Participant |
Robert Cerny
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.