Ticket #602 (accepted Enhancement)

Opened 7 years ago

Last modified 6 years ago

Revise Topicmap Renderer framework

Reported by: jri Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.1.3
Keywords: Cc: dgf, Malte
Complexity: 8 Area: Application Framework / API
Module: deepamehta-webclient

Description

With the upcoming D3 based renderer we have 3 topicmap renderer implementations then:

  • Topicmap (default renderer, Canvas/DOM based)
  • Geomap (OpenLayers?)
  • Topicmap with forces (D3 based)

This is a good opportunity to revise the Topicmap Renderer framework with the focus on sharing code between renderer implementations and reducing boilerplate code.

https://github.com/jri/dm4-d3js-renderer

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 follow-up: ↓ 3 Changed 7 years ago by Malte

Hey jri, I just tried that brand new force-map; looks fluffy :)

What I wanted to note down here (on current state of topicmap renderer_customizations):

  • Often a plugin-developer just wants to implement one specific custom_renderer in a topicmap, one which alters just the visualization of one specific type of topic.

To allow plugins to take over the visualization of an item (in topicmap) per type, the existing "Topicmap renderer" (such as Box, d3js, or Canvas-Renderer) would all need extensions points, I guess. Do you think that would be a good fit for the scope of this ticket?

In any case, I would be glad if you could keep that in mind when approaching this (current) issue.
Thank you very much & nice greets!

comment:3 in reply to: ↑ 2 Changed 7 years ago by jri

Replying to Malte:

  • Often a plugin-developer just wants to implement one specific custom_renderer in a topicmap, one which alters just the visualization of one specific type of topic.

Yes, this is a crucial issue and will be addressed. I have this in mind. However, the D3 renderer needs quite a lot of work first. Crucial architectural questions have to considered, as you have indicated already.

Anyway, I see the importance of type specific customizations as well and we'll solve that.

Thank you for bringing up this issue!

comment:4 Changed 7 years ago by Jörg Richter

Webclient: shared context menu code (#602).

New method in Webclient API:

dm4c.open_context_menu(commands, pos)

Builds a context menu from a set of commands and opens it.
The method is available to several topicmap renderer implementations.

New method in JavaScript? utilities:

js.delete(array, filter)

Deletes array elements that match a filter function. The array is manipulated in-place.

See #602.

comment:5 Changed 7 years ago by Jörg Richter

Webclient: shared context menu code pt.2 (#602).

The method dm4c.open_context_menu(commands, pos) (introduced in previous commit) is replaced by 3 methods:

Webclient API:

dm4c.open_topic_contextmenu(topic_id, pos)
dm4c.open_association_contextmenu(assoc_id, pos)
dm4c.open_canvas_contextmenu(pos, p)

These methods are available to several topicmap renderer implementations. So the renderers must not obtain the commands and pass them to the menu but can instead rely on these high-level methods.

See #602.

comment:6 Changed 6 years ago by jri

There is still copied code which is in principle the same in the default renderer and D3 renderer. See the TODO's in d3_renderer.js.

comment:7 Changed 6 years ago by jri

  • Milestone Release 4.2 deleted
Note: See TracTickets for help on using tickets.