Should we support MODULEs?

[RieksJ]

I have just checked in the ampersand-model: SIAM (Sessions, Identity and Access Management). The idea of being modular is that should be able to just INCLUDE ../SIAM/SIAM.adl, and off you go.

However, if such a module were to need VIEWS, ExecEngine extensions, images or the like, they are not going to be included automatically in a prototype. You would have to copy all that stuff into the INCLUDE directory of your own project to do that, which implies that any updates that may be done in the module (by others) may cause trouble.

I suggest that a means is found, e.g. through the syntax `INCLUDE MODULE ' that will not just INCLUDE the 'File', but also copy the contents of the INCLUDE directory that is located at the 'Path' from where the file was included. Any other/better suggestions?

[sjcjoosten]

Great idea to support modules!

I don't believe it is a good idea to look into a directory relative to the path of a certain file. I do like the idea of modules, so how about a INCLUDE ../SIAM.zip, which will find all .adl files and include files? We are going to need some rules on what to do with conflicting files. For instance: if SIAM.zip and SPAM.zip both include module.adl, we could include both .adl files. If they both contain include/icon.png, we have to choose which of these to use, or maybe throw an error (message: conflicting files, don't know how to combine SPAM.zip/include/icon.png and SIAM.zip/include/icon.png). Any ideas on how you would like these issues solved?

[RieksJ]

Where @sjcjoosten seems to look more from a tool-implementers perspective, I was looking more from a developer perspective. So while @sjcjoosten prefers .zip files, I prefer directories with content that is much more easy to edit (at least until we really know what constitutes a module and what does not). In the meantime, we might support both: I can see where .zip files have benefits.

W.r.t. conflicting files, I can see combinations of two distinct concerns: files having the same name (and same path) and files having the same content. The only situation is where filenames (including path) are the same, AND their content differs. This should produce an error. In all other cases, you can just copy the files.

There is however still something else: the construction of the localSettings.php file. I can imagine that a module might want to append stuff to this file. That would then be an exception to the previous paragraph.

A final issue might be the ability to extend INTERFACEs, see #259.

[sjcjoosten]

I like the rule that files with the same path must have the same content.

My remark about using .zip files was not intended as a tool-implementers perspective: I have had some experience with using 'folders as files', and I seem to constantly run into trouble when sharing it with others, which is what I believe modules are for. But I agree that having a directory instead of a .zip has its benefits while developing a module. I would suggest something like archivemount, but I guess that won't work for windows users, so maybe we do need to support both.

If localSettings.php would contain some code to include all files of the form settings/*.php, then none of the modules would need to contain a localSettings.php file, and we do not have to make exceptions to your excellent rule.

[github-actions]

This issue is stale because it has been open 5 years with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity.

[hanjoosten]

As soon as the initial work on namespaces is done, that paves the way for support for modules.