Changes between Version 1 and Version 2 of Malted/PluginDevelopmentNotes

Timestamp:

20.05.2013 18:50:18 (12 years ago)

Author:

Malte

Comment:

added default workspace and importModels hint, added clientState hint, added default workspace assingment hint

Malted/PluginDevelopmentNotes

@@ -2 +2 @@
 
 == DeepaMehta Webclient Development ==
-
 
 === Implementing Many Simple Renderers ===
@@ -11 +10 @@
 
 After slicing all my simple_renderers into seperate .js-files, webclient startup works fine again.
+
+
+=== 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.
+
+
+=== Working on server-side with dms (Application Service) ===
+
+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.
+
+
+=== 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.*".