Ticket #412 (closed Feature Request: worksforme)
SVG-based Topicmap Renderer
Reported by: | jri | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 4.2 |
Component: | 3rd Party Plugins | Version: | 4.0.14 |
Keywords: | Cc: | dgf, Malte | |
Complexity: | 13 | Area: | |
Module: |
Description
Joern has committed to the task of implementing a SVG-based Topicmap Renderer. This ticket describes the first goal to achieve as well as possible follow-up tasks. The follow-up tasks are not subject of this ticket.
- Overall goal of this ticket is to provide a SVG-based Topicmap Renderer which is fully transparent to the user: a SVG-rendered topicmap must look and interact the same like a standard topicmap as rendered by the (HTML5 Canvas-based) default renderer. In particular: topics are rendered as icons (type-based), colored associations (type-based), move topics, move topic clusters, move topicmap (translate its origin), the selected topic/association is rendered distinctively, trigger commands via context menu.
- Implement the DM Webclient's TopicmapRenderer? interface (JavaScript?). See modules/dm4-webclient/src/main/resources/web/script/interfaces/topicmap_renderer.js. Use the 2 existing topicmap implementations (DefaultTopicmapRenderer? and GeomapRenderer?) as a reference: modules/dm4-webclient/src/main/resources/web/script/renderers/topicmap_renderers/default_topicmap_renderer.js modules/dm4-geomaps/src/main/resources/web/script/topicmap_renderers/geomap_renderer.js
- A SVG-rendered topicmap must rely on the standard Topicmap data format.
- Rendering must rely on the browser's native SVG capabilities (built-in or native plugin). That is, put a <svg> element in the DOM (not a <canvas> element). Use no libraries which emulate SVG (or other object-oriented) rendering via HTML5 Canvas.
- All view changes (e.g. topic moves) must be persistent if and only if the current user has the permission to change the topicmap. Again, use the 2 existing topicmap implementations as reference.
- Deliverable is a DM plugin "dm4-svg-topicmap-renderer". Once it is installed a new topicmap type appears in the "Create Topicmap" dialog box.
- No changes to any other DM module, in particular, Core and Webclient. If the existing Webclient renderer framework proves as not sufficient, its extension must be coordinated with jri.
- The SVG Topicmap Renderer plugin must not compromise the functioning of the DM Core, Webclient, or any other DM plugin.
Estimated realization time is 8 weeks.
In order to meet the estimated realization time it should help if the possible follow-up tasks are *not* addressed before the main goal, as described above, is accomplished. A working plugin with the minimal set of functions described above is of much more value than a fully-featured plugin which never gets done.
Possible follow-up tasks include:
- Extension facility that allows DM plugin developers to provide custom Topic and Association renderings, e.g. non-icon-based topic rendering.
- Individual topic/association renderings on a per-instance basis.
- Switching a topicmap's renderer at runtime (that is view the same topicmap with different renderers).
- Zooming.
The follow-up tasks are explicitly *not* subject of this ticket.
All the follow-up tasks require extensions of the DM Core framework resp. Webclient renderer framework and must be coordinated with jri.
Change History
comment:2 Changed 12 years ago by jri
I would definitely not recommend it.
As described above, for the SVG rendering we don't want rely on HTML canvas (and extra libraries) but exploit the browser's native SVG rendering and DOM manipulation. That is the most natural, canonical, and future-proof way to go.
Related to our concrete task the usage of FabricJS would not reduce our work effort in any way, but *increase* it. At its core the SVG topicmap rendering task is quite minimal: manipulate the DOM dynamically by creating SVG image and line elements. FabricJS would be of no help here. Quite the opposite: you have to learn yet another library. It increases complexity, dependencies, script loading time etc. And you have to learn JavaScript?, jQuery, and the DM framework anyway.
Joern, if you really want become a programmer you have to program. Before you can reasonably judge the benefit of some helper libraries and/or frameworks you have to take the route by feet. There is no way around it. Programming is about endurance, and caring for details. With increasing experience you will realize that usage of libraries and framework comes always at a price. While solving some problems for the experienced programmer they always create new ones. And they will not free you from programming.
I can assure you that using FabricJS will *not* make your task any easier.
I seriously recommend to stick with the concept I have described in this ticket. If you really want accomplish the SVG rendering task your next steps would be:
1) learn the first things about JavaScript?. Read the DM JavaScript? code. Make simple isolated experiments at your own.
2) learn the first things about jQuery. You will need it. Again, read the DM client-side code and do experiments on your own.
3) learn the DM application framework. The server-side parts and the client-side parts. In particular: the client-side TopicmapRenderer? interface and its Geomaps implementation.
Of course I provide you any help you need. As long as no sufficient DM developer documentation exists it is my obligation to help you with the DM related parts. Of course I can help you with JavaScript?, jQuery, SVG, and DOM manipulation as well.
I'm fully aware that the learning curve you have to take now is quite steep. Perhaps it would help you with getting started if I provide you with a plugin template that sets up the SVG rendering context, for you to build on. What do you mean?
comment:3 Changed 12 years ago by joern
Well right now I'am at step 1. The problem that I currently have is how to deal with the infinite scrollability. To place an SVG at a distinct x,y coordinate I need to have a parent to embed it in. This parent provides the coordinate system. The only solution I have so far would be a adaptive svg which is extended on need. This would be ugly I guess. I think the more elegant way would be something like a "field of view". I can than take the translation value of the topicmap to "sort out" everything not visible (actually it would be easier to simply translate the origin of the svg). The visible stuff can than be drawn at the translated coordinates in the svg.
A template would be nice thing, but for now jQuery is the research task :)
comment:4 Changed 12 years ago by joern
I've put some research in jquery. Apparently, there is a SVG-Plugin for jQuery, which we should consider using, since is its designed to deal with big nested svg structs as we are going to use.
Well, I still work about an elegant "SVGish" solution for the infinite Canvas, ideas are welcome.
comment:5 follow-up: ↓ 7 Changed 12 years ago by jri
Let me try to keep you on the track here:
Your 1st milestone should be to bring a DM topicmap on the screen via native SVG rendering.
=> Are you conform with that goal?
If so, it would help you (and me) if you would not care about anything, that is not related to that goal. In particular:
- You don't need continue searching for any helper library. I've explained the background for that decision above.
- You don't need consider anything related to HTML Canvas. I've already stressed that above. Canvas and SVG have nothing to do with each other. Just the contrary: they represent orthogonal different concepts (bitmap vs. object-oriented). Combining these brings no benefit for your task, but only complicate things.
- Don't care about infinite rendering space and draggable screen before the 1st milestone is reached.
- Don't care about interactivity and event handling before the 1st milestone is reached.
After obtaining base capabilities with JavaScript?, jQuery, JSON, and DOM, you must approach the DM framework. If your next questions are related to the DM framework and its API it is a clear sign that you are on the right track.
Perhaps its easier to discuss things personally at a meeting or phone. What do you think?
comment:6 follow-up: ↓ 8 Changed 12 years ago by jri
Hi Joern,
Possibly writing a Topicmap Renderer is currently just to difficult for 3rd-party developers. In particular because it is not very well documented.
I think I have to write a "How to implement a Topicmap Renderer" guide first, or alternatively provide you with a working plugin template.
In the meantime you could strengthen your JavaScript?, jQuery, JSON, and SVG experience.
Sorry for any difficulties.
comment:7 in reply to: ↑ 5 Changed 12 years ago by joern
Replying to jri:
Let me try to keep you on the track here:
Your 1st milestone should be to bring a DM topicmap on the screen via native SVG rendering.
=> Are you conform with that goal?
Depends on how you define "bring it on screen"? Do you want an svg that looks like deepamehta and is rendered programmatically? Thats on the "no problem" side. I know how to do this. The thing left is providing a proof concept, thats what I should do right now.
If so, it would help you (and me) if you would not care about anything, that is not related to that goal. In particular:
- You don't need continue searching for any helper library. I've explained the background for that decision above.
- You don't need consider anything related to HTML Canvas. I've already stressed that above. Canvas and SVG have nothing to do with each other. Just the contrary: they represent orthogonal different concepts (bitmap vs. object-oriented). Combining these brings no benefit for your task, but only complicate things.
Ok, I got that point. I will work with plain jQuery until I find the limition.
- Don't care about infinite rendering space and draggable screen before the 1st milestone is reached.
- Don't care about interactivity and event handling before the 1st milestone is reached.
You are right, but thats no reason for me to not think about it, since my experience in programming says me that 1h of reading documentation is worth 5h of coding. And when I lay a foundation, I first think about what I want to build above it.
After obtaining base capabilities with JavaScript?, jQuery, JSON, and DOM, you must approach the DM framework. If your next questions are related to the DM framework and its API it is a clear sign that you are on the right track.
Indeed, they are coming up :) I know now how to do the rendering. It is in the end just a matter of read the json, filter the stuff I need to display and than get on with rendering. And this is the part where the DM API would be helpful.
Perhaps its easier to discuss things personally at a meeting or phone. What do you think?
Jop, but thats no reason for stop r'n'd :)
comment:8 in reply to: ↑ 6 Changed 12 years ago by joern
Replying to jri:
Hi Joern,
Possibly writing a Topicmap Renderer is currently just to difficult for 3rd-party developers. In particular because it is not very well documented.
I think I have to write a "How to implement a Topicmap Renderer" guide first, or alternatively provide you with a working plugin template.
In the meantime you could strengthen your JavaScript?, jQuery, JSON, and SVG experience.
Sorry for any difficulties.
Indeed, a documentation would be most useful. The other tasks are manageable, its actually not that complicated, the only obstacles here is missing documentation. Maybe a short how-to about how to use the API and what one can do with it would be suitable.
comment:9 Changed 12 years ago by joern
You find the repository for the project at:
https://github.com/joernweissenborn/dm4-svgrenderer
Just the basic foundations where laid so far.
comment:10 Changed 12 years ago by joern
- Status changed from new to accepted
Good news everyone,
Basic functionality was added. I am now able to:
- create an SVG Map
- render all topics visible als balls with text
No functionality is yet include. See github for code.
comment:11 Changed 12 years ago by jri
Great!
comment:12 Changed 12 years ago by joern
A short sitrep after 2 successfull days:
I have now:
- All topics are draggable, new position is persistent
- Assocs are drawn on Init, but not yet updated after drag
This was mainly accomplished by moving all SVG rendering into a TopicRenderer? class. This class takes a topic object. It exposes a render method, with receives a parent DOM as input. On call, it renders the svg and appends it to the parent. Cool thing is, that it can handle events on its own. It can respond to mouse events in its DOM and can change for example its translation value. This this then rendered by browser. Also the update topic method is called via the topicrenderer, right now by firing a post_move_topic event The SVG Renderer Plugin doesn't know about dragging and positioning, all topicsrenderers take care of that themselves. Similiary, assoc rendering is done by a assoc rendering engine. They are similar to topicmaprenderers, but lack eventhandling. Also they take 2 topic objects (to make that possible I extendend the topicmap.js class, iterate_assocs now passes looks up the related topic objects and passes it to the renderer)
My next steps will be:
- update assocs on dragging. This will be a good opporturnity to revise my topic-/assocrender models
- translate my coordinate system
- create topics and assocs
You'll find the actual snap in my github. Please understand that the code is neither documented nor cleaned up right as the plugin is under heavy development. Also I am pretty new to javascriptm so maybe I use dirty methods sometimes.
I would be happy to get some feedback!
comment:13 Changed 12 years ago by joern
Assocs now redraw if one of the topics move. Next step is translating the whole map.
comment:14 Changed 12 years ago by joern
Ok, map dragging is also included now. Next step is creating a new topic.
comment:15 Changed 12 years ago by joern
Newest features:
- topic creation, selection and editing
- assoc selection and editing
Things left to do till 1st Milestone:
- assoc creation
- context menue
- topic and assoc coloring
- code cleanup and documentation
comment:16 Changed 12 years ago by joern
Good news.
the plugin reached a functional status. In terms of interaction and functionality, everything is functional now.
Now its time for colouring. To do that I have to write a mechanism which loads SVG from ressources, based upon the type uri.
comment:17 Changed 12 years ago by joern
The assocs and topics are now using the provided sources from dm4c for rendering.
The Contextmenu is now block based, but not fully functional. Changing this will be the last step before reaching the milestone (plus code review and documentation).
comment:18 Changed 11 years ago by joern
- Cc joern removed
- Status changed from accepted to assigned
- Owner changed from joern to jri
Ticket refused, details are not of public interests. All work can be pulled from mentioned github repo.
comment:19 Changed 11 years ago by jri
- Status changed from assigned to closed
- Resolution set to worksforme
Meanwhile we have D3 based SVG renderer
I think FabricJS could be just what we need, what do you think?