[deepamehta-devel] type qualifying question

Jörg Richter jri at deepamehta.de
Fr Sep 6 18:19:39 CEST 2013


On Sep 3, 2013, at 14:01, Torsten Ziegler wrote:

> I have another question regarding some kind of
> topictype qualifying in relation to the toplevel menu (uppermost bar with
> workspace, topicmap selectors and search, create interface)
> 
> I want to create a custom topicmap type with some additional fields,
> while this works fine the newly created topicmaps of the new type do not show up
> any more in the topicmap selector.
> 
> I could adjust the code in the selector of course but it seems to be more reasonable
> to add some kind of inheritance or qualifying to the newly created topictype that
> signals the other parts of deepamehta that this topictype acts like another type (e.g. a standard topicmap)

Yes, Topicmaps must be of type "dm4.topicmaps.topicmap". Currently there is no other way. Behind the scenes each topicmap is assigned a Topicmap Renderer implementation (identified by URI). The renderer implementation determines the topicmap's view model and (client-side) presentation logic.

DM provides no inheritance and probably never will.
Instead you can associate any type of child topics (simple or composite) to each topic/association instance. The FacetsService (see module dm4-facets) provides support to do so in a type-safe fashion.
To deliver certain facets along with a topic/association via the REST API you can use the server-side PreSend... hooks or the service response filter to enrich a topic/association on-the-fly.
	PreSendTopicListener 
	PreSendAssociationListener 
	PreSendTopicTypeListener 
	PreSendAssociationTypeListener
	ServiceResponseFilterListener

As an example see how the GeomapsPlugin provides a PreSendTopicListener to enrich all Address topics (that are topics of type "dm4.contacts.address") that are delivered via REST with a Geo-Coordinate facet:

    /**
     * Enriches an Address topic with its Geo Coordinate facet.
     */
    @Override
    public void preSendTopic(Topic topic, ClientState clientState) {
        TopicModel address = findAddress(topic);
        if (address == null) {
            return;
        }
        //
        Topic geoFacet = facetsService.getFacet(address.getId(), "dm4.geomaps.geo_coordinate_facet");
        if (geoFacet != null) {
            logger.info("### Enriching address " + address.getId() + " with its geo facet");
            address.getCompositeValueModel().put("dm4.geomaps.geo_coordinate", geoFacet.getModel());
        } else {
            logger.info("### Enriching address " + address.getId() + " with its geo facet ABORTED " +
                "-- no geo facet in DB");
        }
    }

> I thinks this might also be usefull to other parts of deepamehta,
> for example the email plugin does use the dm4-contacts topictypes as
> resources for email adresses. But there might be other usefull resources,
> so a qualifier as "this topictype provides an email address like xx standard topictype"  might be usefull.

If a DM application needs to express the semantics "email address" it should use the topic type "dm4.contacts.email_address" (part of the dm4-contacts module) for that. Other modules can reuse this type for creating its domain specific types (like "Person" or "Institution"). Danny made the dm4-mail module flexible in the way the user can configure what domain specific types to be used for addressing an email. The only prerequisite is the type has a "dm4.contacts.email_address" as (direct or indirect) child-type.
Currently there is no Aliasing mechanism.

Cheers,
Jörg




Mehr Informationen über die Mailingliste devel