Devel Pattern for interconnect plugins/mods

Devel Pattern for interconnect plugins/mods

de Jean Michel -
Número de respuestas: 7

Hi. I'm not if there exists a pattern of the moodle developers when facing this scenario:

- I have 2 modules (let's call them M1, M2 and M3).

-M3 is new module that has table TM3 with information that can be related to M1 and M2.

-We want to update M1 and M2 in such a way that when a user creates a new instance of M1 or M2 it could create also a M3 instance.

 

My doubts:

(1) Do I extend M1/M2 forms to include new fields of M3?

(2) In case of (1) is true, Do I have to change the add_instance of M1/M2 to create the new instance of M3 and create the relationship by hand?

(3) Does it make sense to have M3 mod form that is not going to be used?

(4) Would be better if I use the M3 mod form to include it using Ajax in mod forms of M1/M2?


Complex question, I know. Maybe someone could give me some light to see better

Thanks in advance.

Jean.

Promedio de valoraciones: -
En respuesta a Jean Michel

Re: Devel Pattern for interconnect plugins/mods

de Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

First, it is not what you are asking, but have a look at the $plugin->dependencies bit on http://docs.moodle.org/dev/version.php so see how you can tell Moodle that one of your plugins requires others to be installed.

Now, to come to your actual question which is about module instances, not the module plugin.

I suggest you think very, very hard about what you are really trying to achieve, and whether two separate but linked modules are really the best way to design this. It is an assumption in Moodle, and really this is good encapsulation, that each activity is a separate entity. This affects things like the course editing UI, backup and restore, and so on. Breaking this encapsulation will cause you a lot of pain. If you tell us what you are trying to do from the user's point of view, then we may be able to suggest another way.

What you are suggesting reminds my of that thing in Windows, where you save a web page, and it saves both index.html and a makes a folder index.html_file with all the associated media. That is a pretty nasty hack.

Anyway, if you really insist of doing this, then I can think of two options.

1. as you suggest, do the work in M1_add/update_instance. And delete_instance. And ... When you do this, I suggest you build M3 in line with the way Moodle web services work, with a nice external API defined in an externallib.php function, and then channel all the communication between M1 and M3 through thost functions.

2. The other option is to use Moodle's events system. M3 coudl look out for add/update/delete_module events that relate to isntances of M1, and do the necessary things then.

En respuesta a Tim Hunt

Re: Devel Pattern for interconnect plugins/mods

de Jean Michel -

Hi Tim, 

first of all, thanks for your good answer, it has help me a lot to understand the possibilities and options to achieve what I want.

I think what I want to do is not so difficult, and for sure something similar is done in many places of Moodle core. I'm going to explain you with the current example I'm working on:

-first module is "Resource Mod". 

-the second is a new mod I created, called "Metadata". This contain a table with metadata I want to bind to new resources in the system. So, table resource in M1 is extended with a field that is a foreign key to metadata table in M2.

M2 contains its own mod_form and lib to create instances, but i will never will use it indepently (they are tightly coupled to M1) because it only makes sense when integrated to resources mod. Therefore, I only will create metadata instances when I first create resources instances.

Design problems I detect for this:

-I have to change mod_form in mod_resource to add the new fields for metadata instance in the form to add/edit. I'd like just reuse the form of metadata.

-I can't reuse the existing forms in metadata mod in a clear way. I have to connect the creation of one instance (resource) with the creation of other one (metadata) and creates the relationship between them. Maybe I could redirect the form of mod_resources to the form of mod_metadata passing parameters, but I'm not sure this is the best aproximation to solve this problem.

I'm looking forward more opinions about this.

Have a nice day ! Jean.

En respuesta a Jean Michel

Re: Devel Pattern for interconnect plugins/mods

de Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

The main thing to say here is that metadata is not a mod.

It really comes in two parts. One part is a database table. You can create that using any sort fo plug-in. For example local_metadata. Rather than just associating mete-data with resources, you might want to be more general, and make that database table link to the course_modules table, or even the context table.

The other part of the problem is changing the add/edit resource form (and for any other type of activity you plan to implement this for) to show the extra fields, and then load save the data when editing the activity/resource. Sadly, Moodle does not provide the hooks for this.

The simplest way to get something working would to hack this in to core Moodle code (course/moodleform_mod.php and course/modedit.php). Of course, that is not a very sustainable long-term solution, but one option is to get that working, then worry about re-factoring it into a plugin later.

En respuesta a Tim Hunt

Re: Devel Pattern for interconnect plugins/mods

de Jean Michel -

Hi Tim!

If I have understood you fine, if I link my metadata table with course_modules I would be able to link my metadata instance with each instance of activity/resource in a course. Is this what you meant?

This approximation is very interesting,  though I'm not sure if I can use that because maybe I will have resources or activities that are not linked to a course initially. Think in it as a "repository" in which I add resources/activities with their metadata, and after I can use them to add them to courses.


Thanks for your help. Best regards.

 

Jean.

En respuesta a Jean Michel

Re: Devel Pattern for interconnect plugins/mods

de Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers

Trying to have activities or resources that are not linked to any course is another thing that is likely to to cause you a lot of pain.

However, it does suggest another approach:

Your "resource repository" could be implemented as a Moodle course, using a custom course format to control how the activities are displayed, and any other UI you might require. Of course, typically you would hide this 'course' from students.

Not sure if this will really work, but worth thinking abut.

By the way, what you are trying to do sounds a bit like the Moodle Community Hub idea. http://docs.moodle.org/23/en/Community_hubs. Also, there is a plugin called something like 'Sharing cart' which I think is another similar thing.

En respuesta a Tim Hunt

Re: Devel Pattern for interconnect plugins/mods

de Jean Michel -

Mmmm very interesting your suggestion to use a moodle course as "repository". I've thought about this. This would let teachers add new resources into this "repo course".

The next step would be reuse the resources and activities added to the repo course in other courses that teachers create. I think I should change the mod_form for resources and activities in order to show a "open existing resource/activity" place where teacher could select the activities or resources to be reused.

And the next step would be syncronize the new resources added to courses (resources that are new, not reused) with the repo course. I mean: when I add resources/activities to other courses they should be "linked" to the repo course to be shown there.

What do you think about this?

 

Thanks again, very helpful your comments Tim!

 

Jean.