Version 9 (modified by Malte, 10 years ago) (diff)

added insights of #569

A page for taking my notes on server- and client-side plugin development with DeepaMehta 4.

DeepaMehta Webclient Development

Implementing Many Simple Renderers

It seems to me that one can not register many simple_renderer-implementations* in one js-renderer file.
Doing so, will make the webclient crash on initial startup with random error messages, mostly of the like "(parsererror: TypeCacheError?: topic type "dm4.core.topic_type" not found)".
Hint: A simple_renderer implementaton looks usually like this: dm4c.add_simple_renderer('tld.project.type.renderer_name', { render_info:function(model, $parent){}, render_form:function(model, $parent){}})

After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again.

Implementing the render_form function of a complete page_renderer

This might be a rare case, but it happens. See #569 for full details.

Referencing existing topic instances from client-side topic-models (JavaScript? / JSON Syntax) serialization syntax

    // for deleting or referencing existing topics, child topic array (of the one specific type) needs to look like this 
    // (no full json-objects needs to be constructed here), e.g.:
    [ "del_id:40190", "ref_id:51291", "ref_id:51131", "ref_id:11318"]

For creating new child-topic instances with one big reuquese, the topc models child-topic array needs look like this:
(comment by jri, see updateAggregationMany() in AttachedCompositeValue?. 3 cases are supported:)

    // create new topic and assign it (when no prefix is found. In this case an entire topic object is expected (with ID -1 and URI "")), e.g.:
    [ "del_id:40190", { "id":-1, "uri": "", "type_uri":"dm4.tags.tag", "value": "my_personal_tag"}, "ref_id:51131", "ref_id:11318"]

As soon one knows this syntax, this frees one from the error-prone solution of creating topics in a 1st step, e.g. via AJAX-calls, and reference them in a 2nd step (and all that on client-side)

Working on DeepaMehta's server-side, resp. on your model

Building plugins from source / maven usage

If you build everything from source mvn clean install is what you need to satisfy a projects maven dependencies.

This is a plugins parent pom you want to use (when developing a plugin):


Working on server-side with dms (ApplicationService?

As a rule of thumb: Whenever you pass the ClientState?-Object into a dms.*-call, all necessary ACL- and Workspace-Assignments should be set automatically by DeepaMehta. This happens because the information which "User" is currrently active in which "Workspace" is part of the Session-Cookie.

Constructing a composite (complex) topic object imperatively

One way how i often create new, complex topic instances, in three steps: 1) CompositValueModel?, 2) TopicModel?, 3) Topic

// create the CompositeValueModel
CompositeValueModel fileComposite = new CompositeValueModel();
// build it up according to your model
fileComposite.put("org.deepamehta.moodle.filename", filename);
fileComposite.put("org.deepamehta.moodle.filepath", filepath);
// create a new TopicModel
TopicModel fileModel = new TopicModel(MOODLE_FILE_URI, fileComposite);
// finally create the new topic instance (with proper ACLs)
Topic moodleFile = dms.createTopic(fileModel, clientState);

Introducing my custom types to DeepaMehta's default workspace

Assigning your custom types to a workspace is not yet configurable. And manually assigning custom types to the default workspace opens up space for errors.

So, especially in a clean installation (DB from scratch) your plugins migration assigning your types to the defualt workspace depends on the "de.deepamehta.workspaces"-plugin which initially creates the "Default Workspace Topic (uri: de.workspaces.deepamehta)".

Adding de.deepamehta.workspaces into the line "importModels=" of my plugin.poperties file makes sure that the dm4-workspaces-plugin is started, and thus the default workspace topic is created, before my custom plugin starts running any of its migrations.

Addendum: Since the "importModels=" property influences the starting order of all plugins, a rule of thumb was identified in Ticket #465: "If your plugin introduces new types, you have to import the "de.deepamehta.accesscontrol" model". Otherwise ACL-Entries may not be set correct during installation of your plugin since the ACL-Plugin is not there to do it's job.

DeepaMehtas? default behaviour for new types introduced by a plugin

DeepaMehtas? default behaviour for new (programmatically introduced) types is to not automatically assign type's to a "Workspace" if the types uri does not begin with the identifier "dm4.*".

Introducing (editable) topic instances in a declarative migration, e.g. "Config"-Topics

Since topic instances introduced programmatically within a migration don't get an AccessControlList? set, the developer must take care of this, e.g. in the postInstall-Hook and with/after consuming the AccessControlService?.

Example: Just the user "admin" should be able to edit a certain configuration, as it should happen with the new mapping-moodle plugin:

    public void postInstall() {
        if (aclService != null) { // panic check (allPluginsMustBeActive)
            Topic serviceEndpointUri = getMoodleServiceUrl();
            aclService.setCreator(serviceEndpointUri.getId(), "admin");
            aclService.setOwner(serviceEndpointUri.getId(), "admin");
            AccessControlList aclist = new AccessControlList()
                    .addEntry(new ACLEntry(Operation.WRITE, UserRole.CREATOR));
            aclService.setACL(serviceEndpointUri.getId(), aclist);

Referencing topic instances in a declarative migration

Example giving, referecing an existing topic by uri works like this:

"composite": { "my.topic.type.uri" : "ref_uri:my.awesome.topic.instance.uri" } 

see also