^{[Note: I had intended to post this in the calendar forum, because that's how the thought started, but then it became too generic. So please forgive me the many references to calendar.]}

Hi everyone,

Recently I 've given (separately) some thought to these issues:

1. How do we display calendar blocks in pages other than the course view? Mike's wishes kept pushing at the limits of what the calendar API could do.
2. How do we configure what blocks are displayed in each page? Martin's comments in CVS (correctly) state that this needs to be addressed.

Up to this point, we can draw the conclusions that: 1) we need an administrative interface, 2) we need extensibility to allow calendars to be displayed anywhere. That got me thinking. Too much, maybe. So I came up with this far-reaching and high-aspiring idea, which I had to share...

I will be describing the idea first, and outlining potential uses afterwards.


1. Distinguish between pages where calendars might be displayed

Let's call each of these areas a "domain". For example, each course page is a different domain. The main Moodle index is another domain. category.php and all pages it might display is another domain, etc. However, the course pages have the same domain name. That's useful if we need to distinguish between them, too (i.e., allows more fine-grained control). We can have a table (let's say mdl_domain) which contains records that represent domains. Each domain is distinguished by its ID, its name (an arbitrary string), its number (to distinguish between domains with the same name; the ID wouldn't be that useful here, continue reading) and some "rules" that allow Moodle to deduce which domain we are in based on the URL the user has requested. For example, we might have records like:

DomainID	Name	Number	Script	URL
1	MAIN	0	/index.php
2	COURSE	3	/course/view.php	id=3
3	CATEGORIES	0	/course/category.php

You get the picture....

2. Domains, APIs and performance

Next, a few functions could be added to the Moodle core, for example get_domain(). This one would deduce from the URL what domain we are in, and return its Name. Keeping of course this data in a static variable for caching, should it be called again. get_domain_id() would be much of the same. If we don't want to get ANY performance hit (almost) we can have a set_domain($name, $number) function which would serve to hard-code this information. For example, when in course/view.php?id=3, I know I can set_domain('COURSE', $id) because this is going to be the same in all Moodle installations. So we can set_domain() in the source and get the performance hit of a query in get_domain() only when actually using the extensibility the domain system allows.

3. What was the world doing before domains were invented?

Up till now, all functions of Moodle had to have hard-coded effects. For example: I 'm viewing the course page. So the code that displays it should behave as I expect it to for a course page. That lessens its usefulness as a generic component. Or maybe I want to see a calendar. The calendar has to know where we are, because the links it displays for next/prev month depend on it. So I have to:

• either put into the calendar logic that deduces in what page I am in
• or make the calendar "dumb", and rely on a "higher authority" to give it knowledge about what links to make exactly

The first case is just like a minimalized version of the get_domain() function I described above. The second case can be simulated by a set_domain() from somewhere followed by a get_domain() inside the calendar.

Notice that I 've been talking about calendar because I 'm familiar with its code. But in essence, the same goes for most everything in Moodle. You have to make one of the above two decisions, or otherwise copy/paste and modify similar blocks of code around (not good for maintainability).

4. Give me a reason to choose domains over the MS Office clip helper

Well, let's recap: domains give your code the ability to know where we are, from a human user's point of view. Anything that lets the machine view things from a human perspective has to have truckloads of usefulness. A domain is a "place", so we can assign information to it. For example, we can define access rights to it. Or we can let each user store preferences for it. A few off-the-shelf examples:

1. Case:
   Why insist that, e.g., "editing tutors can do this and that, tutors can do only this, and students can do nothing at all"? What if I want to have a course where everyone can do X? How can I do that? I have to delve into the sourcecode, find all relevant decision-making lines, and change them. What if I later decide that I don't want this, after all?
   Solution:
   If I had domains for my courses, and if the Moodle source was modified to work with the domain logic, then access to function X could be controlled thus: get the domain, see who is authorized for this domain, decide if the user is in the "authorized" list. The catch is in the "authorized list". It should be obvious that this could be entirely administered with a GUI, and not by changing a single line of code.
2. Case:
   What if I don't want calendars in my courses at all? How do I turn them off? (Obviously, my thoughts on how to implement the calendar administrative interface went on a rampage here... )
   Solution:
   Each course is a domain, and all course domains can be collectively recognized too, remember? So the calendar administrative interface just has to work as in "The default for all domains is this. If you want, you can change it. If you want, you can also define exceptions for this default." For example, you can keep the default in "show mini month view" and define an exception "in the COURSE domain, show both the mini month view and the upcoming events". The possibilities for customization are endless!
3. Case:
   You are a developer (that's me! ). You want to make a component that integrates well with Moodle, but also is extremely extensible so that others can play with it and give you wild ideas. The problem is that "integrates well" means "takes things for granted in an illusion of intelligence, so as not to burden the other coders too much" but "extemely extensible" means "allows you to control even the most minute detail, but forces you to provide 148 parameters even for the simplest, most intuitive case".
   Solution:
   if(get_domain() == "UNKNOWN") call_extensible_but_complicated_interface();
   else use_simple_interface_that_works_automagically();
   

I 'm sure that the possible uses could be described a lot better than this! It's only meant to be a sample of the increased functionality...

So:

• If you are a user, domains will allow you to configure a whole slew of things that otherwise were locked into a specific mode of operation.
• If you are a coder, domains will allow your code to behave with intelligence, integrate better with Moodle, and most importantly, will allow your code to be extended in the future faster than you can say 'case:'
  

5. Postscript

Of course, the above is just an outline of this idea. It's incomplete in many points, and I 'd guess the sample mdl_domain structure presented above is about at the level of what a junior coder wannabe would design during lunch break.

My intention was not to present a concrete proposal; rather, it was to "let the genie out of the bottle", and see if anyone else thinks that my ultimate world domination project is a good idea.

I hope to get lots of feedback on this, and especially Martin's view. If nothing else, it's going to be a good design exercise.

Jon