[deepamehta-devel] Fwd: custom renderer question

[Jörn Weißenborn]

---------- Forwarded message ----------
From: Jörn Weißenborn <joern.weissenborn at gmail.com>
Date: 2013/10/25
Subject: Re: [deepamehta-devel] custom renderer question
To: Jörg Richter <jri at deepamehta.de>
Cc: deepamehta-devel at lists.berlios.de


Hi,


2013/10/25 Jörg Richter <jri at deepamehta.de>

>
> HTML based topic rendering BREAKTHROUGH (#505).
>
> HTML based topic rendering has reached a crucial state. It can now
> friendly coexist with Canvas based topic rendering. A DM View Customizer
> can be HTML-based, or Canvas-based, or hybrid. Various View Customizers
> (possibly provided by different DM plugins) can be active at the same time
> and perform together.
>
> Note: also with HTML based topic rendering a Canvas is always involved,
> mainly for drawing the associations.
>
> For the moment a DM View Customizer provides 7 hooks (all are optional):
>
> General:
>     - update_topic() -- sync the view once the model has changed (topic
> content change or retype)
>

=> How is this done? Is every TopicRenderers update event is called upon
every value changes in the model, regardless if its bound to the data auf
the respective topic? Do I register a view instance to a specific topic ID?


>     - move_topic() -- sync the view once the model has changed (topic
> position change)
>

=> So every topic takes care that it is rendered at the exact position? Why
not put a DOM over it and fix it to a location, create a child element and
give the to the customizer. It makes no sense to do the coordinate handling
inside a the TopicRenderer. This should all be done by the
TopicmapRenderer, which should actually also dretect if a topic at a
position is actually visible in the actual canvas view at given x-y
coordinates and prevent rendering. This is crucial for large maps. A good
testcase for performance is by the way the >eduzen DM database. There you
get LARGE maps. One should test how your implementation is performing in
such cases.


> Canvas based:
>     - draw_topic() -- draw a topic on the canvas
>     - on_mousedown() -- intercept mouse events on the canvas
>

=> So if I don't want canvas I can have my own eventhandling with blackjack
and hookers? Great!


> HTML based:
>     - topic_dom() -- provide the topic's basic DOM
>

=> Nice.


>     - topic_dom_appendix() -- modify the topic DOM once it is added to the
> document
>

=> More confusing than useful. Everyone writing the rendering without
canvas will know how to set DOM properties with jquery, which is always
available.


>     - topic_dom_draggable_handle() -- configure which part of the topic
> DOM initiates dragging
>

=> As I understand it I can define a specific child DOM to fire the onDrag
event on the canvas. Do I give the DOM ID as argument or the DOM object?

I still have the following questions:

Model binding: I still don't see how my customize view have a clean 2 way
databinding. So I know I get model updates intiated by my session. But when
I work with others on the same topicmap the changes are afaik not reflected
on the collaborators session without manual reload. Thanks to the
topicupdate event though, I can at least change the model from my
customView.

Here (in german) I wrote to JRI about this.

- Topics sollten sich selbst an Daten binden koennen. Dh auch, das Topics
unabhaengig von anderen Topics ihre DOM updaten koennen. Das ist eine Must
Have um z.b. eine TopicView zu einer kompletten UI werden zu lassen. Oder
wenn ich meinetwegen jetzt wirklich die Daten von Messgeraeten reinfuettern
wuerde, dann muestte ich mir eine Visualisierung z.b. in Form eines Graphen
bauen. Davon habe ich dann schonmal 20 oder so auf eine TMap (mit meinen
2600x1440 hier auf Arbeit kein Problem). Man stelle sich vor 9 davon sind
statisch und einer wird alle 200ms geupdatet, jedes mal die komplette TMap
neurendern wenn ein Update reinkommt waere Wahnsinn, dabei braucht man nur
die rote Linie im Koordinatensystem umzeichenen!

A take-a-way word: One could think this far, that a topic must not have to
be some static data. A topic could also be a function on all connected
topics. Or a composit of functions. Or a full blown app. Just replace e.g.
the note png with a html texteditor. And then make another note include
that (and reflect changes). DeepaMehta wants to be a semantic Application
Platform., as I perceived it. You could be that, the custom view is the
first step. People will need their own UIs!


> To demonstrate HTML based topic rendering the demo Box Renderer plugin is
> now divided into 2 plugins:
>     https://github.com/jri/dm4-box-renderer-canvas
>     https://github.com/jri/dm4-box-renderer-html
>
> So the known dm4-box-renderer (which is now defunct) is actually renamed
> to dm4-box-renderer-canvas. The new dm4-box-renderer-html provides the very
> same look & feel but renders topics as HTML. So you can e.g. inspect the
> topic DOM in the Web Console as usual.
>
> HTML based topic rendering has several advantages. Because drawing, event
> handling and object click detection is performed natively by the browser,
> implementing a HTML based DM View Customizer is much more comfortable due
> to the power of the DOM. Furthermore the topic style is customizable via
> CSS. In contrast on a Canvas there are no objects, just pixels. It means
> laborious work for the View Customizer developer to emulate clickable and
> movable objects on a Canvas.
>
> What did we tell you? ;)


> The heart of the Canvas based Box Renderer consist of 100 lines of code
> (mostly boring geometry calculations). The HTML version consist of 50 lines
> of code (mostly handy jQuery DOM manipulations).
>
> Lets see how much you need for 2 way databinding ;)


> You have 3 choices:
> - Do not install a Box Renderer and get the "classic" DM look & feel
> (which should be as stable as before).
> - Install the Canvas Box Renderer to get Torsten's "modern" look & feel
> (should be stable as well).
> - Install the HTML Box Renderer to get (nearly) the very same modern look
> & feel (there are still minor issues).
> You can even install both Box Renderers together to get a mixed
> experience. This is not very useful in this case, just to demonstrate the
> flexibility.
>
> Testing all 3 scenarios is very appreciated.
>
> Everything is available in DM's and the respective Box Renderer's master
> branches.
>
> Cheers,
> Jörg
>
> Feinavend,

JW
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.deepamehta.de/mailman/private/devel-lists.deepamehta.de/attachments/20131026/ee818a71/attachment.html>