Ticket #505 (closed Enhancement: fixed)
More flexible topicmap rendering
| Reported by: | jri | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | Release 4.2 |
| Component: | DeepaMehta Standard Distribution | Version: | 4.1.1 |
| Keywords: | Cc: | dgf, Malte, ziegi, JuergeN | |
| Complexity: | 8 | Area: | Application Framework / API |
| Module: | deepamehta-webclient |
Description
Plugin authors should be able to adapt the topic and association rendering in the topicmap panel (left side) without implementing an entire custom Topicmap Renderer (that is implementing a new topicmap flavor like the "Geomap").
Basic requirements:
- A plugin can take responsibility for rendering topics/associations of (a) certain type(s) or any types. That is a topicmap can be rendered collaboratively by a number of plugins (while a particular topic/association can not).
- A plugin may decide to render a topic by drawing on the HTML5 Canvas (provided by the Default Topicmap Renderer) or to build a DOM for each topic that overlays the Canvas then. (Association drawing is always assumed to be direct-on-Canvas.)
Further differentiation:
The focus of this ticket is to enable customization of the (HTML5 Canvas based) Default Topicmap Renderer. The customization then applies globally to all standard topicmaps (of flavor "Topicmap" in contrast to "Geomap"). There is no per-topicmap "render style" switch, that is the topicmap model is not extended for now. A per-topicmap "render style" switch would allow the user to view a single topicmap e.g. in "icon style" or in "box style". A "render style" switch could be addressed at a later stage.
The customization addressed in this ticket allows a plugin developer basically 3 things:
- A global change of the topicmap render style, e.g. by replacing the default "icon + label" topic rendering by a "label in box" rendering.
- Render specific topics (based e.g. on type) in an domain specific style, e.g. a "Class" topic could be rendered in the known UML-like style.
- For topics: to choose between HTML5 Canvas based drawing (which is rather "painting") and DOM based rendering (HTML+CSS). Depending on the application domain one could be advantageous over the other.
Further customization aspects like click detection and event handling remain to be conceptualized.
Change History
comment:2 Changed 11 years ago by jri
Topicmap renderer refactoring, pt.1 (#505).
BREAKING CHANGES
In preparation of the imminent refactoring of the topicmap renderer framework some client-side classes are renamed:
Webclient:
DefaultTopicmapRenderer? -> CanvasRenderer?
DefaultTopicmapViewmodel? -> CanvasView?
Topicmaps:
Topicmap -> TopicmapViewmodel?
TopicmapTopic? -> TopicViewmodel?
TopicmapAssociation? -> AssociationViewmodel?
Geomaps:
Geomap -> GeomapViewmodel?
GeomapTopic? -> GeoTopicViewmodel?
=> Plugins which provide a topicmap renderer implementation must be adapted.
Furthermore one object is renamed:
dm4c.canvas -> dm4c.topicmap_renderer
=> Plugins might require to be updated.
See #505.
Changeset: 60afee1648242a7defb618373942ed7d52a73d31
comment:3 Changed 11 years ago by jri
Topicmap renderer refactoring, pt.2 (#505).
Concept: proper separation of model, viewmodel, and view.
- A model contains the domain data.
- 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 view renders a (compatible) viewmodel through a specific renderer technology, e.g. Canvas, HTML, SVG.
- A topicmap renderer binds a viewmodel to a view.
The same viewmodel can the rendered through different views (that are compatible with that viewmodel).
Implementation objectives:
- responsibility for updating the viewmodel is at the respective topicmap renderer (not the Topicmaps plugin).
- no redundant selection model and translation model in viewmodel and view. The viewmodel is authoritative.
The Topicmaps plugin is now a Webclient dependency. It is no longer an optional install.
+++ NOT FUNCTIONAL +++
See #505.
Changeset: fa245ea5ba3f261c0777f8f3773c097c99052c55
comment:4 Changed 11 years ago by Jörg Richter
comment:5 Changed 11 years ago by Jörg Richter
Refactor topicmap renderer framework, pt.4 (#505).
Hiding and deleting topics/association works.
BREAKING CHANGES
TopicmapRenderer? interface:
- remove_topic() replaced by hide_topic() and delete_topic()
- remove_association() replaced by hide_association() and delete_association()
Remember: the topic renderer is responsible for updating the viewmodel now.
+++ NOT FULLY FUNCTIONAL +++
See #505.
comment:6 Changed 11 years ago by Jörg Richter
comment:7 Changed 11 years ago by Jörg Richter
comment:8 Changed 11 years ago by Jörg Richter
comment:9 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.8 (#505).
Move Canvas specific code from renderer (CanvasRenderer?) to view (CanvasView?).
BREAKING CHANGES
TopicmapRenderer? interface:
- close_context_menu() removed
See #505.
comment:10 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.9 (#505).
Polish TopicmapRenderer? interface.
BREAKING CHANGES
2 methods in the TopicmapRenderer? interface are renamed to better express their semantics:
- add_topic() -> show_topic()
- add_association() -> show_association()
The TopicmapRenderer? methods have no refresh_canvas parameter anymore. It is the responsibility of the renderer implementation (not the webclient's) to keep the display up-to-date.
- update_topic(topic, refresh_canvas) -> update_topic(topic)
- update_association(topic, refresh_canvas) -> update_association(topic)
- hide_topic(topic_id, refresh_canvas) -> hide_topic(topic_id)
- hide_association(assoc_id, refresh_canvas) -> hide_association(assoc_id)
- delete_topic(topic_id, refresh_canvas) -> delete_topic(topic_id)
- delete_association(assoc_id, refresh_canvas) -> delete_association(assoc_id)
- reset_selection(refresh_canvas) -> reset_selection()
See #505.
comment:11 Changed 11 years ago by Jörg Richter
comment:12 Changed 11 years ago by Jörg Richter
Topicmaps: fix hiding/deleting associations.
See #505.
comment:13 Changed 11 years ago by Jörg Richter
comment:14 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.1 (#505).
BREAKING CHANGES
In preparation of the imminent refactoring of the topicmap renderer framework some client-side classes are renamed:
Webclient:
DefaultTopicmapRenderer? -> CanvasRenderer?
DefaultTopicmapViewmodel? -> CanvasView?
Topicmaps:
Topicmap -> TopicmapViewmodel?
TopicmapTopic? -> TopicViewmodel?
TopicmapAssociation? -> AssociationViewmodel?
Geomaps:
Geomap -> GeomapViewmodel?
GeomapTopic? -> GeoTopicViewmodel?
=> Plugins which provide a topicmap renderer implementation must be adapted.
Furthermore one object is renamed:
dm4c.canvas -> dm4c.topicmap_renderer
=> Plugins might require to be updated.
See #505.
comment:15 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.2 (#505).
Concept: proper separation of model, viewmodel, and view.
- A model contains the domain data.
- 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 view renders a (compatible) viewmodel through a specific renderer technology, e.g. Canvas, HTML, SVG.
- A topicmap renderer binds a viewmodel to a view.
The same viewmodel can the rendered through different views (that are compatible with that viewmodel).
Implementation objectives:
- responsibility for updating the viewmodel is at the respective topicmap renderer (not the Topicmaps plugin).
- no redundant selection model and translation model in viewmodel and view. The viewmodel is authoritative.
The Topicmaps plugin is now a Webclient dependency. It is no longer an optional install.
+++ NOT FUNCTIONAL +++
See #505.
comment:16 Changed 11 years ago by Jörg Richter
comment:17 Changed 11 years ago by Jörg Richter
Refactor topicmap renderer framework, pt.4 (#505).
Hiding and deleting topics/association works.
BREAKING CHANGES
TopicmapRenderer? interface:
- remove_topic() replaced by hide_topic() and delete_topic()
- remove_association() replaced by hide_association() and delete_association()
Remember: the topic renderer is responsible for updating the viewmodel now.
+++ NOT FULLY FUNCTIONAL +++
See #505.
comment:18 Changed 11 years ago by Jörg Richter
comment:19 Changed 11 years ago by Jörg Richter
comment:20 Changed 11 years ago by Jörg Richter
comment:21 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.8 (#505).
Move Canvas specific code from renderer (CanvasRenderer?) to view (CanvasView?).
BREAKING CHANGES
TopicmapRenderer? interface:
- close_context_menu() removed
See #505.
comment:22 Changed 11 years ago by Jörg Richter
Topicmap renderer refactoring, pt.9 (#505).
Polish TopicmapRenderer? interface.
BREAKING CHANGES
2 methods in the TopicmapRenderer? interface are renamed to better express their semantics:
- add_topic() -> show_topic()
- add_association() -> show_association()
The TopicmapRenderer? methods have no refresh_canvas parameter anymore. It is the responsibility of the renderer implementation (not the webclient's) to keep the display up-to-date.
- update_topic(topic, refresh_canvas) -> update_topic(topic)
- update_association(topic, refresh_canvas) -> update_association(topic)
- hide_topic(topic_id, refresh_canvas) -> hide_topic(topic_id)
- hide_association(assoc_id, refresh_canvas) -> hide_association(assoc_id)
- delete_topic(topic_id, refresh_canvas) -> delete_topic(topic_id)
- delete_association(assoc_id, refresh_canvas) -> delete_association(assoc_id)
- reset_selection(refresh_canvas) -> reset_selection()
See #505.
comment:23 Changed 11 years ago by Jörg Richter
comment:24 Changed 11 years ago by Jörg Richter
Topicmaps: fix hiding/deleting associations.
See #505.
comment:25 Changed 11 years ago by Jörg Richter
comment:26 Changed 11 years ago by Jörg Richter
Webclient: fix default association color.
See #505.
comment:27 Changed 11 years ago by Jörg Richter
Webclient: extend TextWrapper? utility (#505).
The js.TextWrapper? class has 2 new methods:
- get_size() -- returns the size of the wrapped text's bounding box
- get_line_height() -- returns the line height (as passed to the constructor)
This supports writing topicmap renderer customizers.
See #505.
comment:28 Changed 11 years ago by Jörg Richter
Webclient: canvas renderer customizers (#505).
Concept: a Topicmap Renderer Customizer allows a plugin to change the look & feel of the topicmap rendering. A Topicmap Renderer Customizer is bound to a specific Topicmap Renderer, that is you can't e.g. apply a CanvasRenderer? customizer to the Geomaps Renderer (which would make no sense).
Implementation: the default topicmap renderer (CanvasRenderer?) provides a new method that allows 3rd-party plugins to register customizer objects:
add_customizer(customizer)
A customizer object for the CanvasRenderer? is a constructor function which (for the moment) can have 2 methods:
- draw_topic(topic, ctx) -- receives a topic view object and a drawing context and is responsible for drawing the topic. If the customizer feels not responsible for drawing this particular topic it can return true to let drawing to other customizers resp. the default renderer.
- create_topic(topic_viewmodel, ctx) -- receives a topic viewmodel and a drawing context and is responsible for creating the corresponding topic view object. Remember: a view object enriches a viewmodel by information needed for both, drawing and click detection. Most notably that is geometry information. The drawing context can be used e.g. for measuring text.
Each customizer method is optional. If not specified the respective default implementation rules.
You can inspect the default implementation in the new class CanvasDefaultConfiguration?.
To see an example topicmap renderer customizer:
https://github.com/jri/dm4-box-renderer
Try this (in the development environment):
- install the dm4-box-renderer plugin. That is add it to the hotdeploy list in the global POM and restart DM. You'll see the customized rendering style now.
- in the Gogo shell: stop the dm4-box-renderer plugin. You do so by the stop command.
- press reload in browser. You'll see the original render style.
- start the dm4-box-renderer plugin. You'll see the customized render style again.
This illustrates that a 3rd party plugin can customize the default rendering without impairing the default renderer code and without any code doubling.
See #505.
comment:29 Changed 11 years ago by jri
The example BoxRenderer? has proper topic click detection now.
https://github.com/jri/dm4-box-renderer
The entire text box acts as a clickable area.
For this purpose the BoxRenderer? creates a custom TopicView? object via the create_topic() customizer method.
Note: the created TopicView? object has width and height properties. For simple click detection no further measures are necessary as the default topicmap renderer relies on these width and height properties.
Concept: the view object (here: TopicView?) calculates and holds all geometry information needed for both, drawing and click detection. So the calculations must not be performed over and over.
comment:30 Changed 11 years ago by Jörg Richter
Webclient: expand renderer customizers (#505).
Changes in topicmap renderer customizer methods:
- create_topic() -- dropped. Replaced by modify_topic_view().
- modify_topic_view(topic_view, ctx) -- new method. It receives a generic TopicView? object (defined in CanvasView?) and allows the customizer to add its specific properties. This way multiple customers can work collaboratively.
- on_move_topic(topic_view) -- new method. Invoked when a topic is moved. Receives the corresponding TopicView? object and allows the customizer to update its specific properties.
See #505.
comment:31 Changed 11 years ago by Jörg Richter
Webclient: change customizer methods (#505).
Changes in topicmap renderer customizer methods:
- modify_topic_view() renamed to update_topic(). Additionally invoked when a generic TopicView? is updated, that is its label and/or type has changed. The customizer is responsible for updating its depending properties accordingly.
- on_move_topic() renamed to move_topic().
See #505.
comment:32 Changed 11 years ago by jri
Changes in example BoxRenderer:
- Small type icon in lower/right box corner.
- The label text is not truncated.
- The box has a litte padding.
- The box is blue.
So, it looks almost exactly like Torstens suggestion (which I think is great!).
comment:33 Changed 11 years ago by Jörg Richter
Webclient: on_mousedown customizer method (#505).
New topicmap renderer customizer method:
on_mousedown(pos, modifier) -- allows interfering with canvas mousedown events.
pos -- an object with 2 properties:
canvas -- the mouse position in canvas coordinate space (has x/y properties)
topicmap -- the mouse position in topicmap coordinate space (has x/y properties)
modifier -- an object with 1 property:
shift -- state of the shift key (boolean)
Returning true triggers the default behavoir.
Furthermore: the customizer constructor function receives one argument:
canvas_view -- a CanvasView? facade: an object with 1 property:
iterate_topics -- a function which iterates through all ViewTopics? visible on the canvas,
as enriched by customizers. Receives a visitor function which is passed a ViewTopic?.
Returning something from the visitor function stops the iteration and iterate_topics
returns that value.
The CanvasDefaultConfiguration? class is a private CanvasView? class (not located in separate file anymore).
See #505.
comment:34 Changed 11 years ago by jri
- Cc JuergeN added
The BoxRenderer? is updated: the icon acts as a handle to create new associations.
So, the look&feel of Torsten's suggestion is now basically realized.
Realized as a plugin that utilizes DMs new (and evolving) Topicmap Renderer Customization Framework.
Thanks to Torsten Ziegler for the original idea + design!
I see this as a significant improvement of DM's topicmap panel.
And if you don't like it deactivate the plugin and you get the "classic" DM look&feel.
comment:35 Changed 11 years ago by Jörg Richter
Webclient: optimize click detection (#505).
The topic's bounding box is not calculated over and over.
BREAKING CHANGE
Topicmap Renderer Customizers are responsible for adding "x1", "y1", "x2", "y2" properties (the bounding box) to the topic views. Customizers are no longer required to add "width" and "height" properties.
See #505.
comment:36 Changed 11 years ago by Jörg Richter
Topicmaps module: viewmodel customizers (#505).
Plugins can extend the Topicmap viewmodel on-the-fly at server-side. They do so by implementing a ViewmodelCustomizer? and registering it at the Topicmaps plugin. The Topicmaps OSGi service provides one new method:
void registerViewmodelCustomizer(ViewmodelCustomizer customizer)
A ViewmodelCustomizer? implementation has one method:
void modifyViewProperties(Topic topic, CompositeValueModel viewProps)
Before sending a topicmap to the client the Topicmaps plugin calls this method for every topic contained in the map. The plugin then have the opportunity to add view properties (e.g. color, shape) to the CompositeValueModel?. The Topic instance can be used to fetch the view properties from the DB, either through navigation ("get related topic(s)") or through the Property API.
The Topicmaps plugin serializes the CompositeValueModel? as "view" property (in the topic's JSON representation).
As an example see the Box Renderer plugin:
https://github.com/jri/dm4-box-renderer
Note: Currently a ViewmodelCustomizer? is only applicable to the default Topicmap viewmodel, not to the Geomap viewmodel.
BREAKING CHANGE
The Topicmap JSON format has slightly changed. The topic's "visualization" property is now called "view".
"visualization" -> "view"
See #505.
comment:37 Changed 11 years ago by Jörg Richter
Handle custom view props at client-side (#505).
The custom view properties added by a viewmodel customizer at server-side are accessible from a topicmap renderer customizer at client-side. In a TopicView? object the custom view properties are accessible as
tv.view_props[...]
So the circle is now complete. Topics can have individual styles, based on persistent per-topic view properties. At server-side a Viewmodel Customizer can add custom properties (e.g. color, shape) to a topic's viewmodel. At client-side a Topicmap Renderer Customizer have access to these custom properties when rendering a topic.
As an example see the Box Renderer plugin. The topic boxes have individual colors:
https://github.com/jri/dm4-box-renderer
BREAKING CHANGE
The Topicmap JSON format has slightly changed. A topic's "view" property is now called "view_props".
topic.view -> topic.view_props
See #505.
comment:38 Changed 11 years ago by Jörg Richter
Topicmaps: client-side viewmodel customizer (#505)
Nomenclature change: The concept of "Topicmap Renderer Customizer" is renamed to "View Customizer". In correspondence to "Viewmodel Customizer".
Viewmodel Customizers also have a client-side part now. At client-side a plugin can register a Viewmodel Customizer at the Canvas Renderer:
canvas_renderer.add_viewmodel_customizer(customizer_func)
A (client-side) Viewmodel Customizer is a constructor function with 1 method:
modify_view_properties(topic, view_props)
The Canvas Renderer calls this method each time a topic is added to a topicmap. The customizer then have the opportunity to add custom view properties to the "view_props" object. Typically these custom view properties are accessed then by a compatible View Customizer to do custom rendering.
As an example see the Box Renderer plugin:
https://github.com/jri/dm4-box-renderer
Note: for the moment a Viewmodel Customizer is only applicable to the Canvas Renderer (and its default TopicmapViewmodel?), not to the Geomap Renderer.
BREAKING CHANGES
- add_view_customizer() replaces add_customizer()
- add_viewmodel_customizer() is new method
See #505.
comment:39 Changed 11 years ago by Jörg Richter
Topicmaps: store custom view properties (#505).
The server-side viewmodel customizer has a new method:
void storeViewProperties(Topic topic, CompositeValueModel? viewProps)
It is invoked by the Topicmaps plugin when custom view properties needs to be stored in the DB. Its up to the (server-side) viewmodel customizer to store the properties it feels responsible to.
Now the cycle is really complete:
- Topicmaps viewmodels are enriched by custom view properties at server-side. Done by server-side Viewmodel Customizer's enrichViewProperties() method.
- Custom view properties are accessed at client-side to inform the custom rendering. Done by client-side View Customizer's draw_topic() method.
- Topics added to a topicmap are enriched by custom view properties at client-side. Done by client-side Viewmodel Customizer's enrich_view_properties() method.
- Custom view properties of topics added to a topicmap are stored at server-side. Done by server-side Viewmodel Customizer's storeViewProperties() method.
So, plugins can customize the Canvas rendering as well as the underlying viewmodel by implementing a View Customizer (client-side only) and optionally a Viewmodel Customizer (client-side and server-side).
BREAKING CHANGES
Change in (server-side) ViewmodelCustomizer? interface:
- enrichViewProperties() replaces modifyViewProperties()
See #505.
comment:40 follow-up: ↓ 41 Changed 11 years ago by JuergeN
Great! Can someone add the dm4-box-renderer to CI, please? I would like to test it.
comment:41 in reply to: ↑ 40 ; follow-up: ↓ 43 Changed 11 years ago by jri
Replying to JuergeN:
Great! Can someone add the dm4-box-renderer to CI, please? I would like to test it.
Done!
I added a job to Jenkins and initiated a build manually.
Box Renderer will be build automatically every time DM is build.
As "Post Step" I entered "/usr/local/bin/ci_copy_plugin.sh dm4-box-renderer"
Is this correct? Does this mean Box Renderer is copied to our nightly-build live demo? That would be nice.
I'm happy you like to test Box Renderer!
comment:42 Changed 11 years ago by Jörg Richter
Topicmaps: refactor class names (#505).
BREAKING CHANGES:
Package de.deepamehta.plugins.topicmaps.model is dropped.
2 classes are located in the "topicmaps" packgae directly:
- de.deepamehta.plugins.topicmaps.TopicmapViewmodel?
- de.deepamehta.plugins.topicmaps.ClusterCoords?
TopicViewmodel? and AssociationViewmodel? are now private inner classes of TopicmapViewmodel?.
See #505.
comment:43 in reply to: ↑ 41 Changed 11 years ago by JuergeN
Replying to jri:
Replying to JuergeN:
Great! Can someone add the dm4-box-renderer to CI, please? I would like to test it.
Done!
Thx!
I added a job to Jenkins and initiated a build manually.
Box Renderer will be build automatically every time DM is build.
As "Post Step" I entered "/usr/local/bin/ci_copy_plugin.sh dm4-box-renderer"
Is this correct? Does this mean Box Renderer is copied to our nightly-build live demo? That would be nice.
No, it does not not mean it. But have added the plugin to the nighlty distribition, so it should be available in the nighlty demo.
I'm happy you like to test Box Renderer!
Yeah! I think it's cool and heading nto the right direction: a per instance thumbnail / Text with a small indicator! Very nice!
comment:44 Changed 11 years ago by Jörg Richter
Store view properties at client-side (#505).
- View Customization Framework:
The canvas view facade passed to a view customizer constructor has another property:
set_view_properties -- a function with 2 arguments: "topic_id" and "view_props"
The view customizer author can call this function to change view properties at client-side, e.g. once a "style" dialog box is closed. The properties will be changed at 3 spots: the view, the viewmodel, and the DB.
For an example see the Box Renderer:
https://github.com/jri/dm4-box-renderer
- The Topicmaps service's setViewProperties() method is accessible via REST:
PUT /topicmap/{id}/topic/{id} CompositeValueModel in the message body
The REST client is extended correspondingly:
dm4c.restc.set_view_properties(topicmap_id, topic_id, view_props)
- JavaScript? utilities:
js.copy(src_obj, dst_obj) is a new method to copy properties from one object to another.
- Webclient CSS tweaks.
BREAKING CHANGES
- Topicmaps API:
- setViewProperties() replaces updateViewProperties()
- setTopicPosition() replaces moveTopic()
- setClusterPosition() replaces moveCluster()
- GUI Tookit:
- the dialog.open() method has no "no_close_button" parameter anymore. A dialog box always has a close box.
See #505.
comment:45 Changed 11 years ago by jri
The Box Renderer now provides a color dialog for choosing individual topic colors.
To invoke the color dialog choose "Set Color" from the topic context menu.
By default a topic is light blue (random colors are not used anymore).
comment:46 Changed 11 years ago by Jörg Richter
Read out view properties at client-side (#505).
View Customization Framework:
The canvas view facade passed to a view customizer constructor has another property:
get_topic -- a function with a "topic_id" argument
The view customizer author can call this function to access a particular TopicView? object e.g. to read out its view properties.
For an example see the Box Renderer:
https://github.com/jri/dm4-box-renderer
See #505.
comment:47 Changed 11 years ago by Jörg Richter
Topicmaps: unregister viewmodel customizer (#505).
View Customization Framework:
The Topicmaps API has a method to unregister a viewmodel customizer:
void unregisterViewmodelCustomizer(ViewmodelCustomizer customizer)
A viewmodel customizer author should call this method once the Topicmaps service goes away. Otherwise hers plugin might have problems when redeployed.
See #505.
comment:48 Changed 11 years ago by Jörg Richter
Store view properties at client-side (#505).
- View Customization Framework:
The canvas view facade passed to a view customizer constructor has another property:
set_view_properties -- a function with 2 arguments: "topic_id" and "view_props"
The view customizer author can call this function to change view properties at client-side, e.g. once a "style" dialog box is closed. The properties will be changed at 3 spots: the view, the viewmodel, and the DB.
For an example see the Box Renderer:
https://github.com/jri/dm4-box-renderer
- The Topicmaps service's setViewProperties() method is accessible via REST:
PUT /topicmap/{id}/topic/{id} CompositeValueModel in the message body
The REST client is extended correspondingly:
dm4c.restc.set_view_properties(topicmap_id, topic_id, view_props)
- JavaScript? utilities:
js.copy(src_obj, dst_obj) is a new method to copy properties from one object to another.
- Webclient CSS tweaks.
BREAKING CHANGES
- Topicmaps API:
- setViewProperties() replaces updateViewProperties()
- setTopicPosition() replaces moveTopic()
- setClusterPosition() replaces moveCluster()
- GUI Tookit:
- the dialog.open() method has no "no_close_button" parameter anymore. A dialog box always has a close box.
See #505.
comment:49 Changed 11 years ago by Jörg Richter
Read out view properties at client-side (#505).
View Customization Framework:
The canvas view facade passed to a view customizer constructor has another property:
get_topic -- a function with a "topic_id" argument
The view customizer author can call this function to access a particular TopicView? object e.g. to read out its view properties.
For an example see the Box Renderer:
https://github.com/jri/dm4-box-renderer
See #505.
comment:50 Changed 11 years ago by Jörg Richter
Topicmaps: unregister viewmodel customizer (#505).
View Customization Framework:
The Topicmaps API has a method to unregister a viewmodel customizer:
void unregisterViewmodelCustomizer(ViewmodelCustomizer customizer)
A viewmodel customizer author should call this method once the Topicmaps service goes away. Otherwise hers plugin might have problems when redeployed.
See #505.
comment:51 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.1 (#505).
Begin of a new concept: Topics are rendered as HTML, instead of being drawn on the canvas. Thus drawing, event handling, object click detection relies on the native browser capabilities. This simplifies the development of DeepaMehta View Customizers tremendously.
This is in experimental stage. There is a new branch "topic-html". Not fully usable.
Works in conjunction with the Box Renderer "topic-html" branch.
See #505.
comment:52 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.2 (#505).
- Canvas-drawn topics are actually replaced by HTML topics
- Translating the canvas works
Not yet fully usable.
BREAKING CHANGES
1) The Webclient's DOM hierarchy (left panel) is changed:
div#topicmap-panel // topicmap container, stays in document all the time, former ID was "canvas-panel"
div.topicmap-renderer // renderer-specific container, replaced when switching renderer, class is set by framework
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
Before:
div#canvas-panel // topicmap container, stays in document all the time, new ID is "topicmap-panel"
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
2) The topicmap renderer developer is not responsible anymore to equip the renderers DOM element with the ID "canvas".
See #505.
comment:53 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.3 (#505).
In conjunction with the Box Renderer the new HTML-based rendering approaches the original (canvas drawn) state:
- switching topicmaps work
- topics can't exceed the topicmap panel space
- long labels are wrapped
New hook in View Customizer Framework:
topic_dom_appendix(topic_view, topic_dom)
Invoked once the topic's DOM (as provided by the topic_dom hook) is added to the document. At this time the topic DOM is positioned and have a size. The customizer can use this information e.g. to add further geometry-dependent elements to the topic DOM.
BREAKING CHANGES
Webclient convenience method renamed:
dm4c.get_icon_src() -> dm4c.get_type_icon_src()
See #505.
comment:54 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.4 (#505).
Updating topics work.
The topic DOM is hold in the TopicView? objects ("dom" property).
This allows for direct access of the topic DOM. No DOM traversal is required. No topic IDs are stored in the DOM.
See #505.
comment:55 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.5 (#505).
- Hiding and deleting topics works.
- Creating associations works (both, via content menu and via mini icon).
View Customizer Framework:
- Another hook for HTML-based topic rendering:
topic_dom_draggable_handle(topic_dom, handles)
By using this hook a View Customizer can control which part of the topic DOM can initiate dragging, e.g. the Box Renderer excludes the topic's mini icon from being draggable as it serves for creating associations. By default the entire topic DOM can initiate dragging.
- The canvas view facade (passed to a view customizer constructor) has another property:
pos -- a function that takes an "event" argument
View Customizers can call this function to convert a mouse event into a canvas coordinate. This works also if the event occurred in any element of the HTML topic overlay.
BREAKING CHANGES
Changed signature of one Webclient controller method:
dm4c.do_create_association(type_uri, topic_id_1, topic_id_2)
Now it takes 2 topic IDs (instead of a single topic) and can connect arbitrary topics (instead of only the selected one).
See #505.
comment:56 Changed 11 years ago by Jörg Richter
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)
- move_topic() -- sync the view once the model has changed (topic position change)
Canvas based:
- draw_topic() -- draw a topic on the canvas
- on_mousedown() -- intercept mouse events on the canvas
HTML based:
- topic_dom() -- provide the topic's basic DOM
- topic_dom_appendix() -- modify the topic DOM once it is added to the document
- topic_dom_draggable_handle() -- configure which part of the topic DOM initiates dragging
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.
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).
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.
We are ready for merging into master now.
See #505.
comment:57 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.1 (#505).
Begin of a new concept: Topics are rendered as HTML, instead of being drawn on the canvas. Thus drawing, event handling, object click detection relies on the native browser capabilities. This simplifies the development of DeepaMehta View Customizers tremendously.
This is in experimental stage. There is a new branch "topic-html". Not fully usable.
Works in conjunction with the Box Renderer "topic-html" branch.
See #505.
comment:58 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.2 (#505).
- Canvas-drawn topics are actually replaced by HTML topics
- Translating the canvas works
Not yet fully usable.
BREAKING CHANGES
1) The Webclient's DOM hierarchy (left panel) is changed:
div#topicmap-panel // topicmap container, stays in document all the time, former ID was "canvas-panel"
div.topicmap-renderer // renderer-specific container, replaced when switching renderer, class is set by framework
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
Before:
div#canvas-panel // topicmap container, stays in document all the time, new ID is "topicmap-panel"
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
2) The topicmap renderer developer is not responsible anymore to equip the renderers DOM element with the ID "canvas".
See #505.
comment:59 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.3 (#505).
In conjunction with the Box Renderer the new HTML-based rendering approaches the original (canvas drawn) state:
- switching topicmaps work
- topics can't exceed the topicmap panel space
- long labels are wrapped
New hook in View Customizer Framework:
topic_dom_appendix(topic_view, topic_dom)
Invoked once the topic's DOM (as provided by the topic_dom hook) is added to the document. At this time the topic DOM is positioned and have a size. The customizer can use this information e.g. to add further geometry-dependent elements to the topic DOM.
BREAKING CHANGES
Webclient convenience method renamed:
dm4c.get_icon_src() -> dm4c.get_type_icon_src()
See #505.
comment:60 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.4 (#505).
Updating topics work.
The topic DOM is hold in the TopicView? objects ("dom" property).
This allows for direct access of the topic DOM. No DOM traversal is required. No topic IDs are stored in the DOM.
See #505.
comment:61 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.5 (#505).
- Hiding and deleting topics works.
- Creating associations works (both, via content menu and via mini icon).
View Customizer Framework:
- Another hook for HTML-based topic rendering:
topic_dom_draggable_handle(topic_dom, handles)
By using this hook a View Customizer can control which part of the topic DOM can initiate dragging, e.g. the Box Renderer excludes the topic's mini icon from being draggable as it serves for creating associations. By default the entire topic DOM can initiate dragging.
- The canvas view facade (passed to a view customizer constructor) has another property:
pos -- a function that takes an "event" argument
View Customizers can call this function to convert a mouse event into a canvas coordinate. This works also if the event occurred in any element of the HTML topic overlay.
BREAKING CHANGES
Changed signature of one Webclient controller method:
dm4c.do_create_association(type_uri, topic_id_1, topic_id_2)
Now it takes 2 topic IDs (instead of a single topic) and can connect arbitrary topics (instead of only the selected one).
See #505.
comment:62 Changed 11 years ago by Jörg Richter
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)
- move_topic() -- sync the view once the model has changed (topic position change)
Canvas based:
- draw_topic() -- draw a topic on the canvas
- on_mousedown() -- intercept mouse events on the canvas
HTML based:
- topic_dom() -- provide the topic's basic DOM
- topic_dom_appendix() -- modify the topic DOM once it is added to the document
- topic_dom_draggable_handle() -- configure which part of the topic DOM initiates dragging
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.
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).
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.
We are ready for merging into master now.
See #505.
comment:63 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.1 (#505).
Begin of a new concept: Topics are rendered as HTML, instead of being drawn on the canvas. Thus drawing, event handling, object click detection relies on the native browser capabilities. This simplifies the development of DeepaMehta View Customizers tremendously.
This is in experimental stage. There is a new branch "topic-html". Not fully usable.
Works in conjunction with the Box Renderer "topic-html" branch.
See #505.
comment:64 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.2 (#505).
- Canvas-drawn topics are actually replaced by HTML topics
- Translating the canvas works
Not yet fully usable.
BREAKING CHANGES
1) The Webclient's DOM hierarchy (left panel) is changed:
div#topicmap-panel // topicmap container, stays in document all the time, former ID was "canvas-panel"
div.topicmap-renderer // renderer-specific container, replaced when switching renderer, class is set by framework
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
Before:
div#canvas-panel // topicmap container, stays in document all the time, new ID is "topicmap-panel"
canvas#canvas // in case CanvasRenderer is active: the <canvas> element
2) The topicmap renderer developer is not responsible anymore to equip the renderers DOM element with the ID "canvas".
See #505.
comment:65 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.3 (#505).
In conjunction with the Box Renderer the new HTML-based rendering approaches the original (canvas drawn) state:
- switching topicmaps work
- topics can't exceed the topicmap panel space
- long labels are wrapped
New hook in View Customizer Framework:
topic_dom_appendix(topic_view, topic_dom)
Invoked once the topic's DOM (as provided by the topic_dom hook) is added to the document. At this time the topic DOM is positioned and have a size. The customizer can use this information e.g. to add further geometry-dependent elements to the topic DOM.
BREAKING CHANGES
Webclient convenience method renamed:
dm4c.get_icon_src() -> dm4c.get_type_icon_src()
See #505.
comment:66 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.4 (#505).
Updating topics work.
The topic DOM is hold in the TopicView? objects ("dom" property).
This allows for direct access of the topic DOM. No DOM traversal is required. No topic IDs are stored in the DOM.
See #505.
comment:67 Changed 11 years ago by Jörg Richter
Webclient: HTML based topic rendering pt.5 (#505).
- Hiding and deleting topics works.
- Creating associations works (both, via content menu and via mini icon).
View Customizer Framework:
- Another hook for HTML-based topic rendering:
topic_dom_draggable_handle(topic_dom, handles)
By using this hook a View Customizer can control which part of the topic DOM can initiate dragging, e.g. the Box Renderer excludes the topic's mini icon from being draggable as it serves for creating associations. By default the entire topic DOM can initiate dragging.
- The canvas view facade (passed to a view customizer constructor) has another property:
pos -- a function that takes an "event" argument
View Customizers can call this function to convert a mouse event into a canvas coordinate. This works also if the event occurred in any element of the HTML topic overlay.
BREAKING CHANGES
Changed signature of one Webclient controller method:
dm4c.do_create_association(type_uri, topic_id_1, topic_id_2)
Now it takes 2 topic IDs (instead of a single topic) and can connect arbitrary topics (instead of only the selected one).
See #505.
comment:68 Changed 11 years ago by Jörg Richter
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)
- move_topic() -- sync the view once the model has changed (topic position change)
Canvas based:
- draw_topic() -- draw a topic on the canvas
- on_mousedown() -- intercept mouse events on the canvas
HTML based:
- topic_dom() -- provide the topic's basic DOM
- topic_dom_appendix() -- modify the topic DOM once it is added to the document
- topic_dom_draggable_handle() -- configure which part of the topic DOM initiates dragging
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.
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).
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.
We are ready for merging into master now.
See #505.
comment:69 Changed 11 years ago by Jörg Richter
Webclient: Fix DOM based topic rendering (#505).
- Move cluster works
- Retype topic works
- While drawing an association topics can be crossed
- Remove topic highlight when an association is selected
- Set topic color works (Box Renderer Plugin)
View Customization Framework:
- new hook (Canvas & HTML):
update_view_properties(topic_view)
Used by customizer to update the rendering once custom view properties have changed.
See #505.
comment:70 Changed 11 years ago by Jörg Richter
Webclient: Fix DOM based topic rendering (#505).
- Move cluster works
- Retype topic works
- While drawing an association topics can be crossed
- Remove topic highlight when an association is selected
- Set topic color works (Box Renderer Plugin)
View Customization Framework:
- new hook (Canvas & HTML):
update_view_properties(topic_view)
Used by customizer to update the rendering once custom view properties have changed.
See #505.
comment:71 Changed 11 years ago by Jörg Richter
comment:72 Changed 11 years ago by Jörg Richter
Webclient: rename 3 view customizer hooks (#505).
BREAKING CHANGE
View Customization Framework:
- 3 hooks are renamed:
- update_topic() -> on_update_topic()
- move_topic() -> on_move_topic()
- update_view_properties() -> on_update_view_properties()
The "on" prefix tells: "the underlying topic viewmodel has changed. Now, dear view customizer, its up to you to sync the view accordingly". Syncing the view includes:
a) update possible viewmodel-related custom properties e.g. the topic's bounding box (in case of Canvas based rendering).
b) update the topic DOM (in case of DOM based rendering).
See #505.
comment:73 Changed 11 years ago by Jörg Richter
comment:74 Changed 11 years ago by Jörg Richter
Webclient: rename 3 view customizer hooks (#505).
BREAKING CHANGE
View Customization Framework:
- 3 hooks are renamed:
- update_topic() -> on_update_topic()
- move_topic() -> on_move_topic()
- update_view_properties() -> on_update_view_properties()
The "on" prefix tells: "the underlying topic viewmodel has changed. Now, dear view customizer, its up to you to sync the view accordingly". Syncing the view includes:
a) update possible viewmodel-related custom properties e.g. the topic's bounding box (in case of Canvas based rendering).
b) update the topic DOM (in case of DOM based rendering).
See #505.
comment:76 Changed 11 years ago by jri
See also #522
comment:77 Changed 11 years ago by Jörg Richter
Core: extend DeepaMehtaObject? API (#522, #505).
The DeepaMehtaObject? base interface specifies a new method:
void loadChildTopics(String childTypeUri)
It loads the object's childs specified by its type URI.
If the childs are loaded already nothing is performed.
Can be used for both, "one" and "many"-valued childs.
This method is of interest for Viewmodel Customizer implementers (see #505).
See #522.
comment:78 Changed 11 years ago by Jörg Richter
Use composite values for in-map rendering (#505).
View Customizer Framework:
The client-side TopicViewmodel? and TopicView? objects expose the underlying topic's "composite" property.
Thus view customizers can involve the topic's composite value for rendering (not just the topic label).
To do so a server-side Viewmodel Customizer is required to provide the desired composite topic values, that is to load certain child topics (by using Topic's new loadChildTopics() method), e.g.:
@Override
public void enrichViewProperties(Topic topic, CompositeValueModel viewProps) {
if (topic.getTypeUri().equals("dm4.notes.note")) {
topic.loadChildTopics("dm4.notes.text");
}
}
In this example for all Note topics contained in the topicmap the note's body text is loaded and thus becomes part of the topicmap sent to the client.
At client-side the View Customizer access the note's text like this:
if (topic_view.type_uri == "dm4.notes.note") {
var text = topic_view.composite["dm4.notes.text"].value
}
See #505.
comment:79 Changed 11 years ago by Jörg Richter
Change "on_update_view_properties" trigger (#505).
View Customization Framework:
The "on_update_view_properties" hook is invoked additionally once a TopicView? is instantiated.
This is the same invocation pattern as with the "on_update_topic" hook.
Thus DOM based view customizers can call its view-prop-synching behavoir from 1 location only.
See #505.
comment:80 Changed 11 years ago by Jörg Richter
Expand canvas view facade by update_topic (#505).
View Customization Framework:
The canvas view facade (as passed to a view model customizer) has a new method
update_topic(topic)
A view customizer calls this method to update the view e.g. once topic childs are loaded in response of clicking an expansion handle.
It updates the TopicViewmodel? and the TopicView? according to the changed domain topic, fires the "on_update_topic" customizer hook, renders the canvas, and (in case of a DOM based customizer) repositions the topic DOM.
See #505.
comment:81 Changed 11 years ago by Jörg Richter
Reposition topic DOM on view prop update (#505).
View Customization Framework:
After invoking the "on_update_view_properties" hook the framework adjusts the position of the topic DOM. This allows view customizers to perform size affecting topic DOM manipulations within "on_update_view_properties".
E.g. when an expansion handle (whose state is stored as a view property) is clicked the size of the topic DOM changes. The customizer must not care about repositioning the topic DOM.
See #505.
comment:82 Changed 11 years ago by Jörg Richter
Core: extend DeepaMehtaObject? API (#522, #505).
The DeepaMehtaObject? base interface specifies a new method:
void loadChildTopics(String childTypeUri)
It loads the object's childs specified by its type URI.
If the childs are loaded already nothing is performed.
Can be used for both, "one" and "many"-valued childs.
This method is of interest for Viewmodel Customizer implementers (see #505).
See #522.
comment:83 Changed 11 years ago by Jörg Richter
Use composite values for in-map rendering (#505).
View Customizer Framework:
The client-side TopicViewmodel? and TopicView? objects expose the underlying topic's "composite" property.
Thus view customizers can involve the topic's composite value for rendering (not just the topic label).
To do so a server-side Viewmodel Customizer is required to provide the desired composite topic values, that is to load certain child topics (by using Topic's new loadChildTopics() method), e.g.:
@Override
public void enrichViewProperties(Topic topic, CompositeValueModel viewProps) {
if (topic.getTypeUri().equals("dm4.notes.note")) {
topic.loadChildTopics("dm4.notes.text");
}
}
In this example for all Note topics contained in the topicmap the note's body text is loaded and thus becomes part of the topicmap sent to the client.
At client-side the View Customizer access the note's text like this:
if (topic_view.type_uri == "dm4.notes.note") {
var text = topic_view.composite["dm4.notes.text"].value
}
See #505.
comment:84 Changed 11 years ago by Jörg Richter
Change "on_update_view_properties" trigger (#505).
View Customization Framework:
The "on_update_view_properties" hook is invoked additionally once a TopicView? is instantiated.
This is the same invocation pattern as with the "on_update_topic" hook.
Thus DOM based view customizers can call its view-prop-synching behavoir from 1 location only.
See #505.
comment:85 Changed 11 years ago by Jörg Richter
Expand canvas view facade by update_topic (#505).
View Customization Framework:
The canvas view facade (as passed to a view model customizer) has a new method
update_topic(topic)
A view customizer calls this method to update the view e.g. once topic childs are loaded in response of clicking an expansion handle.
It updates the TopicViewmodel? and the TopicView? according to the changed domain topic, fires the "on_update_topic" customizer hook, renders the canvas, and (in case of a DOM based customizer) repositions the topic DOM.
See #505.
comment:86 Changed 11 years ago by Jörg Richter
Reposition topic DOM on view prop update (#505).
View Customization Framework:
After invoking the "on_update_view_properties" hook the framework adjusts the position of the topic DOM. This allows view customizers to perform size affecting topic DOM manipulations within "on_update_view_properties".
E.g. when an expansion handle (whose state is stored as a view property) is clicked the size of the topic DOM changes. The customizer must not care about repositioning the topic DOM.
See #505.
comment:87 Changed 11 years ago by Jörg Richter
Defer topic DOM positioning (#505).
View Customization Framework: Initial positioning of the topic DOM is deferred until the "on_update_topic" and "on_update_view_properties" hooks are invoked.
As a consequence the customizer's "topic_dom" code must no longer build up the topic DOM as far as its size is computable (but can rely on its "on_update_topic" and "on_update_view_properties" code for doing so). Thus the view-sync behavoir is called from 1 spot only. View Customizer developement is simplified.
See #505.
comment:88 Changed 11 years ago by Jörg Richter
comment:89 Changed 11 years ago by Jörg Richter
Defer topic DOM positioning (#505).
View Customization Framework: Initial positioning of the topic DOM is deferred until the "on_update_topic" and "on_update_view_properties" hooks are invoked.
As a consequence the customizer's "topic_dom" code must no longer build up the topic DOM as far as its size is computable (but can rely on its "on_update_topic" and "on_update_view_properties" code for doing so). Thus the view-sync behavoir is called from 1 spot only. View Customizer developement is simplified.
See #505.
comment:90 Changed 11 years ago by Jörg Richter
comment:91 Changed 11 years ago by Jörg Richter
Fix double click with DOM based renderers (#505).
View Customization Framwork:
The Webclient's "topic_doubleclicked" event is fired for DOM based renderers as well.
E.g. double clicking a File topic works (the file is opened in its origin application).
BREAKING CHANGE
A domain topic (a Topic object) is passed to the topic_doubleclicked handler (not a ViewTopic? object).
See #505.
comment:92 Changed 11 years ago by Jörg Richter
Fix double click with DOM based renderers (#505).
View Customization Framwork:
The Webclient's "topic_doubleclicked" event is fired for DOM based renderers as well.
E.g. double clicking a File topic works (the file is opened in its origin application).
BREAKING CHANGE
A domain topic (a Topic object) is passed to the topic_doubleclicked handler (not a ViewTopic? object).
See #505.
comment:93 Changed 11 years ago by Jörg Richter
comment:94 Changed 11 years ago by jri
- Status changed from accepted to closed
- Resolution set to fixed
The first incarnation of the Topicmap Renderer Framework is regarded complete.
