Changes between Version 4 and Version 5 of Malted/PluginDevelopmentNotes


Ignore:
Timestamp:
27.06.2013 00:53:55 (11 years ago)
Author:
Malte
Comment:

added postinstall hook, and acl-entry example for declarative topics

Legend:

Unmodified
Added
Removed
Modified
  • Malted/PluginDevelopmentNotes

    v4 v5  
    1111After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again. 
    1212 
     13== Working on DeepaMehta's server-side, resp. on your model == 
     14 
     15 
     16=== Working on server-side with dms (ApplicationService === 
     17 
     18As 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. 
    1319 
    1420=== Introducing my custom types to DeepaMehta's default workspace === 
     
    2228Addendum: 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.  
    2329 
    24 === Referencing topic instances in a declarative migration === 
    25  
    26     "composite": { "my.topic.type.uri" : "ref_uri:my.awesome.topic.instance.uri" } see https://github.com/jri/deepamehta/blob/master/modules/dm4-core/src/main/java/de/deepamehta/core/model/CompositeValueModel.java 
    27  
    28 === Working on server-side with dms (Application Service) === 
    29  
    30 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. 
    31  
    3230 
    3331=== DeepaMehtas default behaviour for new types introduced by a plugin === 
    3432 
    3533DeepaMehtas 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.*".  
     34 
     35 
     36=== Introducing (editable) topic instances in a declarative migration, e.g. "Config"-Topics === 
     37 
     38Since 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. 
     39 
     40Example: Just the user "admin" should be able to edit a certain configuration, as it should happen with the new mapping-moodle plugin: 
     41 
     42 
     43{{{ 
     44    @Override 
     45    public void postInstall() { 
     46        if (aclService != null) { // panic check (allPluginsMustBeActive) 
     47            Topic serviceEndpointUri = getMoodleServiceUrl(); 
     48            aclService.setCreator(serviceEndpointUri.getId(), "admin"); 
     49            aclService.setOwner(serviceEndpointUri.getId(), "admin"); 
     50            AccessControlList aclist = new AccessControlList() 
     51                    .addEntry(new ACLEntry(Operation.WRITE, UserRole.CREATOR)); 
     52            aclService.setACL(serviceEndpointUri.getId(), aclist); 
     53        } 
     54    } 
     55 
     56 
     57}}} 
     58 
     59=== Referencing topic instances in a declarative migration === 
     60 
     61Example giving, referecing an existing topic by uri works like this: 
     62 
     63{{{  
     64 
     65"composite": { "my.topic.type.uri" : "ref_uri:my.awesome.topic.instance.uri" }  
     66}}} 
     67 
     68see also https://github.com/jri/deepamehta/blob/master/modules/dm4-core/src/main/java/de/deepamehta/core/model/CompositeValueModel.java