| | 18 | Plugin Development Framework: |
| | 19 | * A plugin can store **Node Properties**. Node properties are topic/association metadata like timestamps, ACL information, or geo coordinates. The new Property API can retrieve topics/associations based on property value or value range (#472). Node properties can be indexed. Numeric properties are trie-indexed which allows for performant range queries. Ranges are particularly useful for time-based or geo-based retrieval (#490). Property keys are namespaced (#491). |
| | 20 | * HTTP response generation: |
| | 21 | * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484, #481). |
| | 22 | * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationException if a 500 response is intended (#484). |
| | 23 | * (REST) resource methods can use an arbitrary class for the entity parameter as long as the representation is JSON and the class has a public JSON constructor. Implementing a custom JAX-RS provider class is no longer required (#277). |
| | 24 | * 3 new Core Events: |
| | 25 | * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480). |
| | 26 | * `RESOURCE_REQUEST_FILTER` allows plugins to manipulate or interrupt static resource requests (#480). |
| | 27 | * `SERVICE_RESPONSE_FILTER` allows plugins to manipulate REST service responses, e.g. by setting certain response headers (#477). |
| | 28 | * Webclient: |
| | 29 | * (Client-side) plugins can send REST service requests asynchronously (#476). |
| | 30 | * New Webclient event (client-side): `pre_send_request` allows plugins to investigate and manipulate a request before it is send to the server (#486). |
| | 31 | * The default topicmap view model is renderer agnostic. It is reusable by different topicmap renderer implementations (#443). |
| | 32 | * Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458). |
| | 33 | * Core Service: there are methods for retrieving ''all'' topics/associations from the DB. These are useful for migrations which transform the entire database (#495). |
| | 34 | * Core API and standard plugin APIs: the get/retrieve/delete service methods no longer require the `clientState` parameter (#496). |
| | 35 | |
| 15 | | * |
| 16 | | * Logout works for private DM installations as well. (A private DM installation is one with `read_requires_login=true`.) The missing HTTP Logout is emulated by forcing the browser to bring up a dummy login dialog (#423). |
| 17 | | * Login works for open DM installations as well. (An open DM installation is one with `read_requires_login=false` and `write_requires_login=false`.) (#475). |
| 18 | | * When wrong credentials are entered DM's login dialog is not overlapped by the browser's login dialog. The user stays in DM's login dialog (#471). |
| 19 | | * When the user enters neither a username nor a password in the login dialog no exception occurs (#473). |
| | 37 | * !Login/Logout: |
| | 38 | * Logout works for private DM installations as well. (A private installation is one with `read_requires_login=true`.) Missing HTTP Logout is worked around by bringing up a bogus browser login dialog (#423). |
| | 39 | * Login works for open DM installations as well. (An open installation is one with `write_requires_login=false`.) (#475). |
| | 40 | * When the user enters wrong credentials in DM's login dialog the browser's login dialog does not appear. The user stays in DM's login dialog (#471). |
| | 41 | * When the user enters neither a username nor a password in the login dialog and presses OK no error occurs (#473). |
| 28 | | Plugin Development Framework: |
| 29 | | * A plugin can store **Node Properties**. Node properties are topic/association metadata like timestamps, ACL information, or geo coordinates. The new Property API can retrieve topics/associations based on property value or value range (#472). Node properties can be indexed. Numeric properties are trie-indexed which allows for performant range queries. Ranges are particularly useful for time-based or geo-based retrieval (#490). Property keys are namespaced (#491). |
| 30 | | * 3 new Core Events: |
| 31 | | * `SERVICE_REQUEST_FILTER` allows plugins to manipulate or interrupt REST service requests (#480). |
| 32 | | * `RESOURCE_REQUEST_FILTER` allows plugins to manipulate or interrupt static resource requests (#480). |
| 33 | | * `SERVICE_RESPONSE_FILTER` allows plugins to set certain response headers (#477). |
| 34 | | * The Core Service provides methods for retrieving ''all'' topics/associations from the DB. These are useful for migrations which transform the entire database (#495). |
| 35 | | * Simplified API: the Core API's and standard plugin service's get/retrieve/delete methods no longer require the `clientState` parameter (#496). |
| 36 | | * Revised exception handling: |
| 37 | | * A plugin can produce specific HTTP (error) responses by throwing a WebApplicationException from its resource methods or event handlers (#484, #481). |
| 38 | | * Exceptions thrown from resource methods or event handlers must no longer be wrapped in a WebApplicationException if a 500 response is intended (#484). |
| 39 | | * (REST) resource methods can use an arbitrary class for the entity parameter as long as the entity is represented in JSON and the class has a public JSON constructor. Implementing a custom JAX-RS provider class is no longer required (#277). |
| 40 | | * Access Control API: there are methods for retrieving topics/associations based on creator or owner (#458). |
| 41 | | * Webclient: |
| 42 | | * New Webclient event (client-side): `pre_send_request` allows plugins to investigate and manipulate a request before it is send to the server (#486). |
| 43 | | * The default topicmap view model is renderer agnostic. It is reusable by different renderer implementations (#443). |
| 44 | | * Plugins can send REST service requests asynchronously (#476). |
| 45 | | |
