Changes between Version 15 and Version 16 of Malted/PluginDevelopmentNotes
- Timestamp:
- 08.07.2014 12:09:47 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Malted/PluginDevelopmentNotes
v15 v16 1 1 A page for taking my notes on server- and client-side plugin development with DeepaMehta 4. 2 2 3 = = DeepaMehta Webclient Development ==3 = Table of Contents = 4 4 5 === Webclient Hooks: Reacting to events of the dm4-webclient === 5 On this page you find my personal notes (as hints) for: 6 6 7 * DeepaMehta Webclient Development 8 * DeepaMehta Service Development 9 * Stuff to keep in mind when designing your new plugin 10 11 12 = DeepaMehta Webclient Development = 13 14 == Webclient Hooks: Reacting to events of the dm4-webclient == 15 7 16 For a most probably up-to-date list of all events currently fired by the DeepaMehta 4 Webclient see https://github.com/jri/deepamehta/blob/master/modules/dm4-webclient/src/main/resources/docs/events.txt or your local copy 8 17 of that under $DM-Home/modules/dm4-webclient/. 9 18 10 == = Implementing Many Simple Renderers ===19 == Implementing Many Simple Renderers == 11 20 12 21 '''It seems to me that one can not register many simple_renderer-implementations* in one js-renderer file.''' [[BR]] … … 16 25 After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again. 17 26 18 19 === Implementing the render_form function of a complete page_renderer === 27 == Implementing the render_form function of a complete page_renderer == 20 28 21 29 This might be a rare case, but it happens. See #569 for full details. 22 30 23 == = Referencing existing topic instances from client-side topic-models (JavaScript / JSON Syntax) serialization syntax ===31 == Referencing existing topic instances from client-side topic-models (JavaScript / JSON Syntax) serialization syntax == 24 32 25 33 For creating a complete composite (with all new/or existing child-topics) in one Request, the topic models (JSON) array of child-topics needs to use the following semantics like this:[[BR]] … … 47 55 As soon one knows this syntax, it frees the developer from the error-prone solutions of creating topics in multiple-steps, e.g. creating them independently (e.g. in JavaScript) in a 1st step and then reference them in a 2nd step. 48 56 49 = = Working on DeepaMehta's server-side, resp. on your model ==57 = DeepaMehta Service Development = 50 58 51 59 == DeepaMehta Core-Service exposed via REST == … … 53 61 Have a look at all annotated core-service methods in ''de.deepamehta.plugins.webservice.WebservicePlugin'' which is available with the DeepaMehta SourceCode and to find in the ''modules/dm4-webservice'' module. 54 62 55 == = Building plugins from source / maven usage ===63 == Building plugins from source / maven usage == 56 64 57 65 If you build everything from source {{{mvn clean install}}} is what you need to satisfy a projects maven dependencies. … … 67 75 }}} 68 76 69 == = Working on server-side with dms (ApplicationService ===77 == Working on server-side with dms (ApplicationService == 70 78 71 79 As a rule of thumb: Whenever you pass the ''ClientState''-Object into a dms.*-call, the Workspace-Assignment will be set automatically by DeepaMehta. This happens because the information which "User" is currrently active in which "Workspace" is part of the Session-Cookie. Vice-versa: If you pass ClientState a ''null'' into a createTopic call your topic will most probably have no "Workspace" assigned at all and you should do so manually. … … 86 94 87 95 88 == == Constructing a composite (complex) topic object imperatively ====96 == Constructing a composite (complex) topic object imperatively == 89 97 90 98 One way how i often create new, complex topic instances, in three steps: 1) CompositValueModel, 2) TopicModel, 3) Topic … … 102 110 }}} 103 111 104 == = Introducing my custom types to DeepaMehta's default workspace ===112 == Introducing my custom types to DeepaMehta's default workspace == 105 113 106 114 '''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.''' … … 112 120 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. 113 121 114 == = Introducing a shared workspace and set up your topics to editable by all members of this shared workspace ===122 == Introducing a shared workspace and set up your topics to editable by all members of this shared workspace == 115 123 116 124 A proper workspace assignment in DeepaMehta involves the "Username"-Topic (and not the "User Account"-Topic) to be the: … … 127 135 128 136 129 == = DeepaMehtas default behaviour for new types introduced by a plugin ===137 == DeepaMehtas default behaviour for new types introduced by a plugin == 130 138 131 139 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.*". 132 140 133 141 134 == = Introducing (editable) topic instances in a declarative migration, e.g. "Config"-Topics ===142 == Introducing (editable) topic instances in a declarative migration, e.g. "Config"-Topics == 135 143 136 S ince 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.144 SSince 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. 137 145 138 146 Example: Just the user "admin" should be able to edit a certain configuration, as it should happen with the new mapping-moodle plugin: … … 153 161 }}} 154 162 155 == = Referencing topic instances in a declarative migration ===163 == Referencing topic instances in a declarative migration == 156 164 157 165 Example giving, referecing an existing topic by uri works like this: … … 163 171 164 172 see also https://github.com/jri/deepamehta/blob/master/modules/dm4-core/src/main/java/de/deepamehta/core/model/CompositeValueModel.java 173 174 175 176 = Stuff to keep in mind when designing your new plugin = 177 178 > I hope you can take something out of my observations (see below) of the FF API and some of my experiences I made when starting a DM4 plugin. 179 180 Read more at http://lists.deepamehta.de/pipermail/devel-lists.deepamehta.de/2014-June/000499.html 181
