Ticket #505 (closed Enhancement: fixed)

Opened 7 years ago

Last modified 7 years ago

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:

  1. A global change of the topicmap render style, e.g. by replacing the default "icon + label" topic rendering by a "label in box" rendering.
  2. 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.
  3. 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:1 Changed 7 years ago by joern

  • Cc joern removed

comment:2 Changed 7 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?

CanvasTopic? -> TopicView?
CanvasAssoc? -> AssociationView?

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 7 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 7 years ago by Jörg Richter

Refactor topicmap renderer framework, pt.3 (#505).

Creating and updating topics/association works.

+++ NOT FULLY FUNCTIONAL +++

See #505.

comment:5 Changed 7 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 7 years ago by Jörg Richter

Refactor topicmap renderer framework, pt.5 (#505).

Refactoring is basically done.

+++ FUNCTIONAL +++

See #505.

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

Refactor topicmap renderer framework, pt.6 (#505).

Remove unused code.

See #505.

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

Refactor topicmap renderer framework, pt.7 (#505).

Move certain cluster code from view to viewmodel.

BREAKING CHANGES

Topicmaps plugin: rename REST client methods

dm4c.restc.move_topic() -> dm4c.restc.set_topic_position()
dm4c.restc.move_cluster() -> dm4c.restc.set_cluster_position()

See #505.

comment:9 Changed 7 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 7 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 7 years ago by Jörg Richter

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

comment:14 Changed 7 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?

CanvasTopic? -> TopicView?
CanvasAssoc? -> AssociationView?

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 7 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 7 years ago by Jörg Richter

Refactor topicmap renderer framework, pt.3 (#505).

Creating and updating topics/association works.

+++ NOT FULLY FUNCTIONAL +++

See #505.

comment:17 Changed 7 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 7 years ago by Jörg Richter

Refactor topicmap renderer framework, pt.5 (#505).

Refactoring is basically done.

+++ FUNCTIONAL +++

See #505.

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

Refactor topicmap renderer framework, pt.6 (#505).

Remove unused code.

See #505.

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

Refactor topicmap renderer framework, pt.7 (#505).

Move certain cluster code from view to viewmodel.

BREAKING CHANGES

Topicmaps plugin: rename REST client methods

dm4c.restc.move_topic() -> dm4c.restc.set_topic_position()
dm4c.restc.move_cluster() -> dm4c.restc.set_cluster_position()

See #505.

comment:21 Changed 7 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 7 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 7 years ago by Jörg Richter

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

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

comment:27 Changed 7 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 7 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):

  1. 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.
  2. in the Gogo shell: stop the dm4-box-renderer plugin. You do so by the stop command.
  3. press reload in browser. You'll see the original render style.
  4. 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 7 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 7 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 7 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 7 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!).

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

comment:33 Changed 7 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 7 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.

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

comment:35 Changed 7 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 7 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 7 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 7 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

CanvasRenderer?:

  • add_view_customizer() replaces add_customizer()
  • add_viewmodel_customizer() is new method

See #505.

comment:39 Changed 7 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:

  1. Topicmaps viewmodels are enriched by custom view properties at server-side. Done by server-side Viewmodel Customizer's enrichViewProperties() method.
  2. Custom view properties are accessed at client-side to inform the custom rendering. Done by client-side View Customizer's draw_topic() method.
  3. 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.
  4. 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 7 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 7 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 7 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:

TopicViewmodel? and AssociationViewmodel? are now private inner classes of TopicmapViewmodel?.

See #505.

comment:43 in reply to: ↑ 41 Changed 7 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 7 years ago by Jörg Richter

Store view properties at client-side (#505).

  1. 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

  1. 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)
  1. JavaScript? utilities:

js.copy(src_obj, dst_obj) is a new method to copy properties from one object to another.

  1. Webclient CSS tweaks.

BREAKING CHANGES

  1. Topicmaps API:
    • setViewProperties() replaces updateViewProperties()
    • setTopicPosition() replaces moveTopic()
    • setClusterPosition() replaces moveCluster()
  1. 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 7 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).

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

comment:46 Changed 7 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 7 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 7 years ago by Jörg Richter

Store view properties at client-side (#505).

  1. 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

  1. 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)
  1. JavaScript? utilities:

js.copy(src_obj, dst_obj) is a new method to copy properties from one object to another.

  1. Webclient CSS tweaks.

BREAKING CHANGES

  1. Topicmaps API:
    • setViewProperties() replaces updateViewProperties()
    • setTopicPosition() replaces moveTopic()
    • setClusterPosition() replaces moveCluster()
  1. 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 7 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 7 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 7 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 7 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 7 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 7 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 7 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:

  1. 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.

  1. 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 7 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 7 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 7 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 7 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 7 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 7 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:

  1. 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.

  1. 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 7 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 7 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 7 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 7 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 7 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 7 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:

  1. 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.

  1. 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 7 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 7 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 7 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 7 years ago by Jörg Richter

Webclient: change 2 topic DOM hooks (#505).

BREAKING CHANGE

View Customization Framework:

  • 2 hooks don't have the topic_dom parameter anymore, just the topic_view:
    • topic_dom(topic_view)
    • topic_dom_appendix(topic_view)
    The topic DOM is available (as usual) at topic_view.dom

See #505.

comment:72 Changed 7 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 7 years ago by Jörg Richter

Webclient: change 2 topic DOM hooks (#505).

BREAKING CHANGE

View Customization Framework:

  • 2 hooks don't have the topic_dom parameter anymore, just the topic_view:
    • topic_dom(topic_view)
    • topic_dom_appendix(topic_view)
    The topic DOM is available (as usual) at topic_view.dom

See #505.

comment:74 Changed 7 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:75 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:76 Changed 7 years ago by jri

See also #522

comment:77 Changed 7 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 7 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 7 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 7 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 7 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 7 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 7 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 7 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 7 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 7 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 7 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 7 years ago by Jörg Richter

View customization transaction handling (#505).

View Customization Framework:
A viewmodel customizer is not required to create a transaction within the storeViewProperties() hook.
Creating the transaction is handled by the framework.

See #505.

comment:89 Changed 7 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 7 years ago by Jörg Richter

View customization transaction handling (#505).

View Customization Framework:
A viewmodel customizer is not required to create a transaction within the storeViewProperties() hook.
Creating the transaction is handled by the framework.

See #505.

comment:91 Changed 7 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 7 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 7 years ago by Jörg Richter

Webclient: fix highlight on create assoc (#505).

When an association is created (and thus selected) the current topic selection is removed.
In conjunction with DOM based Box Renderer.

See #505.

comment:94 Changed 7 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.

Note: See TracTickets for help on using tickets.