[deepamehta-devel] custom renderer question

Torsten Ziegler torsten at ziegi.de
Di Sep 24 10:30:13 CEST 2013

Hi Jörg,
I got one coment
and some Infos see below...

also i will start a new thread about click detectecion...

Am 21.09.2013 22:03, schrieb Jörg Richter:
> In general it is not possible to switch the renderer for an existing topicmap, because the topicmap viewmodels might not be compatible. It makes no sense e.g. to render a Geomap with the default Canvas renderer. The default viewmodel loader would fail as a default topicmap has another DB layout as a Geomap.
> If, on the other hand, the topicmap viewmodels *are* compatible you probably would *not* implement a complete topicmap renderer but use the upcoming hooks to customize the rendering. With the new rendering hooks you'll be able to selectively render certain topics or all topics, and you'll be able to suppress the default rendering as well. Maintenance would be easier as you would have no redundant/copied code.
> Just some general hints about the (new) topicmap renderer framework:
> Concept: proper separation of model, viewmodel, and view.
>      - A **model** contains the domain data (Topics).
>      - A **viewmodel** contains the domain data to be displayed, enriched by view data (e.g. color values, coordinates). A viewmodel is agnostic to a specific renderer technology. A viewmodel class is responsible for loading a viewmodel from the server/DB and for writing changes back.
>      - A **view** renders a (compatible) viewmodel through a specific renderer technology, e.g. Canvas, HTML, SVG.
>      - A **topicmap renderer** binds a viewmodel to a view. A topicmap renderer class implements the TopicmapRenderer interface and is responsible for consistently updating the viewmodel and the view.
>      - Each **topicmap** is assigned to the responsible topicmap renderer
> The same viewmodel can the rendered through different views (that are compatible with that viewmodel). That is e.g. a SVG renderer with the same look and feel as the default Canvas renderer would utilize the standard TopicmapViewmodel and must not implement its own (with all the server/DB code). Its *View* code would be different of course.

So wouldn't it be the better way to assign the topicmap to a viewmodel
and not the renderer ?
Then every renderer that is impementing the viemodel is allowed to render
the topicmap.
This would allow switch between compatible renderers and to share
topicmaps between differnt render technologies.
One application for this could be:
- create a topicmap in some kind of default renderer (on a desktop computer)
- present it in a "presentation renderer" with differnt user interface
customized to the needs of a lecturer (on a projection screen)

I would like to go this way...

> Can you tell me about your application? What data do you want render on the canvas? How interaction should work? Do you utilize a custom topicmap viewmodel?
Right now I am using the standard viemodel
and am working on more information centered canvas,
see attached image.
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 
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 
and using the standard renderer will be shown without shape but the big 

What to you think?


Torsten Ziegler
torsten at ziegi.de

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : Bildschirmfoto_dm4_enhancedrenderer_2013_09_24.png
Dateityp    : image/png
Dateigröße  : 142659 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.deepamehta.de/mailman/private/devel-lists.deepamehta.de/attachments/20130924/4ded8747/attachment.png>

Mehr Informationen über die Mailingliste devel