[deepamehta-devel] custom renderer question

Jörg Richter jri at deepamehta.de
Sa Sep 21 22:03:05 CEST 2013

Hi Torsten,

sorry for the late response.
I felt you're on the right track. To start with copying/adapting the default renderer and transfer your custom code to the new hooks, once they are introduced, seems reasonable to me. I'm happy to find you in a mood for experimentation :-)

On Sep 15, 2013, at 14:25, Torsten Ziegler wrote:

> Actually I realized that I do not need the HTML Node,
> but am happy to draw directly on the canvas.

That's good to know!
It will make my things more easy for a start.

> (And also I fear that using HTML nodes on the canvas
> will make the mouse interaction slower, as we might
> to have go through the DOM to find the clicked object)

(Not necessarily. Performant clicked object detection on a Canvas requires reasonable effort too. And that is code YOU or I have to write as it's not done by the browser.)

> I guess the hooks will be in the
> default_topicmap_renderer.js
> in the functions draw_topics and draw_associations ?

I plan to equip the default topicmap renderer with a "draw_topic" hook. That hook will receive a view-topic and a Canvas drawing context. Your plugin is free to paint the view-topic on the canvas then.

> I would also like to interfere with the topic selection
> in default_topicmap_viemodel.js in the functions
> find_topic and find_association

Yes, when you do custom topic rendering you should also supply a corresponding "topic click detector". I plan to introduce another hook for that.

> and with the mouse event functions in the default_topicmap_renderer.js

Do you want e.g. handle "topic clicked" events in your own fashion (and suppress the standard behavior which is "show topic details in the detail panel")?
That sounds reasonable to me. I would introduce another hook for that.
What else events do want to interfere with?

> I think a good start for me ist to first rewrite a copy of the default renderer
> to see how things are working out and then communicate with you
> about which hooks are needed and if the things i do seem usefull for others.
> Then I am willing to adapt the code I write to the hooks you provide
> along with the ticket 505.

That sounds very good to me.

On Sep 21, 2013, at 19:22, Torsten Ziegler wrote:

> I have one question regarding the replacement of
> the standard default renderer.
> I started to write a plugin that implements a new
> topicmap renderer (yet a mere copy of the default renderer,
> based on the topicmap-renderer branch as of this morning,
> see attached zip for implementation)
> This works fine but it gets used only on newly created topicmaps
> that are created to be used with this renderer.
> And as soon as I remove the plugin the topicmap can no longer
> be displayed as obviously the renderer is missing.
> Actually this behaviour is not what I like to have.
> I would prefer to replace the default renderer and
> in case my new render is not available to fall back to the
> default renderer.
> I tried to use the uri dm4.webclient.default_topicmap_renderer to
> replace the default  renderer but run into problems maybe due to
> the framework not initializing the renderer properly as it thinks it is
> still the old one.
> Also using js.extend to overwrite the webclient's CanvasRenderer
> and CavasView did not work due to mising initialization.
> Is there any way to replace the default renderer or is this
> not the desired way to go for deepamehta ??

Yes, I understand.
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.

However, this is not the complete answer to your question. We *could* imagine dynamic assignment between topicmap and renderer. We would need then a facility for maintaining what are compatible views for a certain viewmodel.

> I can think of a migration to change the dm4.topicmaps.topicmap_renderer_uri
> for all topicmaps using the default renderer, but this seems quite ugly,
> doesnt it ?

See above.

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.

I think we are on a good track and I'm keen to advance things further.

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?


Mehr Informationen über die Mailingliste devel