Advancing the moodle case

[Malte]

The moodle ​moodle plugin for DM is already functional but feels a bit too rattly to use to hand it out to end users. By now the communication between these two systems need to be triggered by a user on a specific topic via a topic commands like "Ask for my moodle courses" and "Load course contents". I see the need to connect these two systems somehow more magically.

The communication of DM with a remote moodle installation is made of 3 more or less "technical requests" on behalf of each user. I see that there is the necessity to trigger these calls automatically, triggered by hooks of the DM framework.

For example, I could imagine that it makes sense that the ​mapping-moodle-plugin reacts on a DeepaMehta users login in terms of: Whenever a user logs into DeepaMehta (and has a moodle security key set), the DeepaMehta plugin issues 2 requests on behalf of the user:

# getMoodleCourses() - to check if there are any (new) courses the user is participating in, and for any of these course call subsequently
# getCourseContents() - to check if there are any (new) course materials to index for DM

In this scenario a plugin would have the need to be able to react upon an event (like "user authenticated" for example) fired by the dm4-accesscontrol module.

I just wanted to ask what are your thoughts on this and is there already a way to realize this with the current DM?

[Malte]

Here is a working link to the mapping-moodle module: ​https://github.com/mukil/mapping-moodle - trac makes somehow fun out of link-labels. Furthermore here you find a working snapshot of your this moodle plugin compatible with DM 4.1.2:

​http://download.deepamehta.de/nightly/moodle-plugin-1.1.2-SNAPSHOT.jar

To setup a compatible web service definition for this checkout the README in the github repo.

[jri]

Yes, a server-side DM "ON_LOGIN" event definitely makes sense with your Moodle scenario, and would be useful for other DM applications as well. Currently there is no such server-side event and it would require some Core extension first.

But there is a "logged_in" event at client-side already, which you could probably use:

dm4c.add_listener("logged_in", function(username) {
    ...
})

There you would issue a request against your DM Moodle REST service, which in turn would perform the getMoodleCourses() and other calls against the Moodle installation.

[jri]

For the technical background about why a server-side ON_LOGIN event would require a Core extension see #290 (reopened). The point is the ON_LOGIN event is *not* fired by the Core but, as you said, by a plugin, namely Access Control.

[jri]

Meanwhile we have a server-side event extension facility. See #290.

[Jörg Richter]

Access Control: LOGIN and LOGOUT events (#538).

The Access Control module fires custom events once a user logs in or out.

Your plugin can listen to these events analogous to core events:

import de.deepamehta.plugins.accesscontrol.event.PostLoginUserListener;
import de.deepamehta.plugins.accesscontrol.event.PostLogoutUserListener;

public class TimePlugin extends PluginActivator implements PostLoginUserListener,
                                                           PostLogoutUserListener {
    @Override
    public void postLoginUser(String username) {
        ...
    }

    @Override
    public void postLogoutUser(String username) {
        ...
    }
}

Don't forget to put Access Control in your plugin's dependencies (pom.xml):

<dependency>
    <groupId>de.deepamehta</groupId>
    <artifactId>deepamehta-accesscontrol</artifactId>
    <version>4.2-SNAPSHOT</version>
</dependency>

See #538.
See #290.

• Changeset: b6c430ad3cd1968e4ef42652cb14412c684538df
• URL: ​https://github.com/jri/deepamehta/commit/b6c430ad3cd1968e4ef42652cb14412c684538df

[Malte]

Great news, I have just implemented such a listener and it works for the first time.

Just one thing: The ACL-Plugin seems to be waiting until my (or even any) observer which is implementing this listener has done its business.

Cause now:

• My update logic (querying a remote service for the particular user) blocks the login dialog (initially) for quite some time
• If something goes wrong in any of the observers implementing this listeners, e.g. a RuntimeException? is thrown, login fails though it actually succeeded.

Furthermore: When my plugins consumes this type of listener, wouldn't it be nice to render some sort of information to the just logging in user? Imagine something like: "Login successfull. The Moodle Plugin just started to check all your courses for new materials".

So, is there a way to change this and what do you think about such possible extension?

[Malte]

One other thing: In the listener implementation I may want to create (or update) some topics, isn't it crucial to have a users ClientState? available then? If so, is there a way I can construct a proper one given just the "username"? Thanks for your help.

Edited: "to create (OR UPDATE) some topics" - It looks like I can't do that without a ClientState?, at least I get a NullPointerException? if I pass "null" as ClientState?. Can you confirm this?

[Malte]

To clarify:

• A ClientState?-Object is just needed for automatic Workspace-Assignment of topic (can be done manually)
• I imlpemented a Thread() so my Worker does not block the login process (this way the listener can return to ACL-Plugin firing the postLoginEvent() before my sync-job is done)

I have updated my /wiki/Malted/PluginDevelopmentNotes accordingly.
Details are also to find in ​https://github.com/mukil/mapping-moodle/commit/63707cca92f14f9dd37416f3db06ab965b3881e9

Next up: #539 - At best through employing the new dm4-websockets-modules :)

Thanks for your support, this worked fine for me.