Changes between Version 4 and Version 5 of Malted/PluginDevelopmentNotes
- Timestamp:
- 27.06.2013 00:53:55 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Malted/PluginDevelopmentNotes
v4 v5 11 11 After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again. 12 12 13 == Working on DeepaMehta's server-side, resp. on your model == 14 15 16 === Working on server-side with dms (ApplicationService === 17 18 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. 13 19 14 20 === Introducing my custom types to DeepaMehta's default workspace === … … 22 28 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. 23 29 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.java27 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 32 30 33 31 === DeepaMehtas default behaviour for new types introduced by a plugin === 34 32 35 33 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.*". 34 35 36 === Introducing (editable) topic instances in a declarative migration, e.g. "Config"-Topics === 37 38 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. 39 40 Example: 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 61 Example 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 68 see also https://github.com/jri/deepamehta/blob/master/modules/dm4-core/src/main/java/de/deepamehta/core/model/CompositeValueModel.java