[deepamehta-devel] custom renderer question

Jörg Richter jri at deepamehta.de
Di Okt 22 23:50:43 CEST 2013


Hi Torsten et al.,

as you've possibly noticed there is considerable progress on the new View Customization Framework and the example Box Renderer plugin. The Box Renderer plugin uses the Customization Framework to realize your ideas shown in your screenshot. As I said before I see this new Canvas look & feel as a real improvement and contemplate to make it DMs standard look & feel.

Here I want provide you with a quick overview about the current state of the View Customization Framework.

By the means of the View Customization Framework a DM plugin can register 2 types of artifacts:

1) A **View Customizer** intercepts drawing and event handling at client-side. It provides hooks to
- Draw a topic on the canvas. Drawing is informed by a TopicView object which holds all content and geometry data needed for both, actual drawing and topic click detection. A TopicView object is build upon a TopicViewmodel which represents the viewmodel as read from the DB.
- Update a TopicView object once the underlying TopicViewmodel changes, that is content or geometry change (e.g. topic label, topic type, topic position).
- Intercept with mousedown events.
Furthermore a View Customizer provides access to all the TopicView objects of the current topicmap. This allows for
	- iterating over all topics, e.g. to check weather a certain part of the topic is clicked.
	- accessing the view properties of a particular topic, e.g. to provide a GUI for editing them.
	- setting the view properties of a paricular topic, e.g. when a "Topic Style" dialog is submitted.

2) A **Viewmodel Customizer** allows to extend a topic viewmodel by custom view properties (e.g. per-topic color and shape values). A Viewmodel Customizer has a client-side part and a server-side part. It provides hooks to
- Enrich a topic viewmodel by custom view properties at server-side once it is retrieved from the DB (when the client requests a topicmap). The custom view properties are then accessible at client-side for topic rendering.
- Enrich a TopicViewmodel at client-side with default values when a new topic is created.
- Store custom view properties in the DB.

Note that implementing a Viewmodel Customizer is optional. It makes perfect sense for a View Customizer to operate on the standard topicmap viewmodel yet customizing the rendering and/or event handling.

The objective for introducing View Customizers and Viewmodel Customizers is to allow the developer to customize distinct aspects like viewmodel, drawing, event handling, click detection, style configuration dialogs/GUI. The developer overrides the hooks she needs selectively without the need for boilerplate code. In particular she is *not* required to implement an entire Topicmap Renderer (like the Geomaps renderer) and a corresponding server-side topicmap viewmodel (including all its fetch/store DB operations).

As an example which illustrates all the things sketched out above see the implementation of the BoxRenderer plugin. (As with all DM plugins) the server-side Java part is contained in BoxRendererPlugin.java and the client-side JavaScript part in resources/web/script/plugin.js
https://github.com/jri/dm4-box-renderer

Let me know if there are any questions.

Cheers,
Jörg


On Sep 24, 2013, at 10:30, Torsten Ziegler wrote:

> I will introduce
> a) to render topic labels in specific shapes
> For this I will need new properties in the Topic to store (and select)
> shapes (oval, square, star etc.) and colours.
> I think I can read this information through the standard viemodel
> while rendering the view. Or would it be better to implement a new viewmodel?
> I would happy to use the standard viewmodel and have the functionality
> that using my advanced renderer the topics will be shown with the new features
> and using the standard renderer will be shown without shape but the big icon.




Mehr Informationen über die Mailingliste devel