Changes between Version 15 and Version 16 of Malted/PluginDevelopmentNotes


Ignore:
Timestamp:
08.07.2014 12:09:47 (6 years ago)
Author:
Malte
Comment:

Added a link to devel-mailing and improved page-structure

Legend:

Unmodified
Added
Removed
Modified
  • Malted/PluginDevelopmentNotes

    v15 v16  
    11A page for taking my notes on server- and client-side plugin development with DeepaMehta 4. 
    22 
    3 == DeepaMehta Webclient Development == 
     3= Table of Contents = 
    44 
    5 === Webclient Hooks: Reacting to events of the dm4-webclient ===  
     5On this page you find my personal notes (as hints) for: 
    66 
     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  
    716For 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  
    817of that under $DM-Home/modules/dm4-webclient/. 
    918 
    10 === Implementing Many Simple Renderers === 
     19== Implementing Many Simple Renderers == 
    1120 
    1221'''It seems to me that one can not register many simple_renderer-implementations* in one js-renderer file.''' [[BR]] 
     
    1625After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again. 
    1726 
    18  
    19 === Implementing the render_form function of a complete page_renderer === 
     27== Implementing the render_form function of a complete page_renderer == 
    2028 
    2129This might be a rare case, but it happens. See #569 for full details. 
    2230 
    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 == 
    2432 
    2533For 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]] 
     
    4755As 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. 
    4856 
    49 == Working on DeepaMehta's server-side, resp. on your model == 
     57= DeepaMehta Service Development = 
    5058 
    5159== DeepaMehta Core-Service exposed via REST == 
     
    5361Have 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. 
    5462 
    55 === Building plugins from source / maven usage === 
     63== Building plugins from source / maven usage == 
    5664 
    5765If you build everything from source {{{mvn clean install}}} is what you need to satisfy a projects maven dependencies. 
     
    6775}}} 
    6876 
    69 === Working on server-side with dms (ApplicationService === 
     77== Working on server-side with dms (ApplicationService == 
    7078 
    7179As 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. 
     
    8694 
    8795 
    88 ==== Constructing a composite (complex) topic object imperatively ==== 
     96== Constructing a composite (complex) topic object imperatively == 
    8997 
    9098One way how i often create new, complex topic instances, in three steps: 1) CompositValueModel, 2) TopicModel, 3) Topic 
     
    102110}}} 
    103111 
    104 === Introducing my custom types to DeepaMehta's default workspace === 
     112== Introducing my custom types to DeepaMehta's default workspace == 
    105113 
    106114'''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.'''  
     
    112120Addendum: 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.  
    113121 
    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 == 
    115123 
    116124A proper workspace assignment in DeepaMehta involves the "Username"-Topic (and not the "User Account"-Topic) to be the:  
     
    127135 
    128136 
    129 === DeepaMehtas default behaviour for new types introduced by a plugin === 
     137== DeepaMehtas default behaviour for new types introduced by a plugin == 
    130138 
    131139DeepaMehtas 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.*".  
    132140 
    133141 
    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 == 
    135143 
    136 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. 
     144SSince 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. 
    137145 
    138146Example: Just the user "admin" should be able to edit a certain configuration, as it should happen with the new mapping-moodle plugin: 
     
    153161}}} 
    154162 
    155 === Referencing topic instances in a declarative migration === 
     163== Referencing topic instances in a declarative migration == 
    156164 
    157165Example giving, referecing an existing topic by uri works like this: 
     
    163171 
    164172see 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 
     180Read more at http://lists.deepamehta.de/pipermail/devel-lists.deepamehta.de/2014-June/000499.html 
     181