[deepamehta-devel] custom renderer question

[Jörg Richter]

Hi Torsten,

thank you very much for the response which is full of meat :-)
Your suggestion to bind a topicmap to the viewmodel (not to the renderer) is very good!
And your current development as reflected by the screenshot with the customized canvas is very inspiring to me!


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

> 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.
> 
> 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...


This is a very good hint!
Indeed, binding a topicmap to a viewmodel (not to a renderer) is the more natural and flexible approach.
OK, lets 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 like your customized canvas (and the way you present your concepts graphically) very much!
This is decent graphic and interaction design, in particular:
	- Making the topic label/text the most prominent item (not the icon) while retaining a (small) type icon.
	- Not truncating the topic label/text
	- Creating associations without (hidden) right-click or shift-key.
The result is a higher information density on the canvas and better usability.
I feel quite enthusiastic about this obvious improvement!

Actually your screenshot was so inspiring to me that I took it as the reference when designing the Topicmap Customization Framework which I'm currently working on.
On the basis of the current Customization Framework I created a DM plugin "Box Renderer" that realizes your customized canvas look&feel (regarding the 3 aspects listed above). While being functional the plugin also demonstrates how to use the new Topicmap Customization Framework. 
https://github.com/jri/dm4-box-renderer


> 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.
> 
> What to you think?


Yes, you could use the standard topicmap viewmodel and extend it on-the-fly with the additional shape and color information. You could store that view data as properties either of the topic or of the "Topic Mapcontext" association (for per-topicmap individual topic appearance).

With topic/association properties I mean the new Property API introduced DM 4.1.1 which seems suitable here. Properties are arbitrary key-value pairs that need no explicit type definition.
As an alternative you could explicitly define a (composite) topic type for modeling the view data (color, shape, ...).

With "extending on-the-fly" I mean the use of the SERVICE_RESPONSE_FILTER event to manipulate a Topicmap object before it is send to the webclient. See https://trac.deepamehta.de/ticket/515 in particular comment #2. In your filter you would iterate the topicmap's topics and for each one retrieve its view properties (via Property API) and place them in the topic's "visualization" CompositeValueModel (see comment #1 in that ticket).

You would need support from my side at 2 spots: 1) The Topicmap model class (server-side) needs a public topic iterator, 2) Accessing your view properties at client-side needs support in the Topicmap Customization Framework.

Please tell me if you need help/support.


Torsten, I would love to continue in this very modus. That is, you provide actual application use cases and graphic/interaction designs. I use them as a reference case for further designing the application framework. Thus DM would benefit from your great designs/ideas and at the same time we are sure the framework will be good for real applications. This kind of co-evolution feels very fruitful and enjoyable to me.


Cheers,
Jörg