Right, the more you ask for here, which you did not ask for in your blog, is exactly what Urs is asking for.
I don't think Joomla (sorry, Joomla!) is a good comparison for Moodle. I was investigating it today to see what I could learn, and the answer was not much. Some conclusions:
* Whoever thought of calling it Joomla!
should be shot. No, that is too good for them! If I see another exclamation mark I am going to scream! More to the point, it really hurts the readability of documentation to have random punctuation in the middle of sentences.
* Oh, and I really hope that Moodle Docs
comes across better to a newcomer than the Joomla documentation wiki does. If I see another stub page, I am going to scream some more.
OK, I'll be sensible now ...
When I say Joomla is not a good comparison for Moodle, what I mean is that, from what I could see, if you take Moodle, throw away everything except blocks, and then add the blocks and themes enhancements that I am proposing for Moodle 2.0, then you are very close to Joomla. (That is a very rough approximation.) The one thing that the front end of a Joomla site does not have much of is interaction. Moodle has a lot of it.
Themeing a Joomla site is mostly about making templates for a lot of fairly static content. Then behind the scenes there is a whole lot of editing User interface that most people don't bother to theme, because only admins ever see it, although it can be templated if you want. (Can I just make it clear, this is not a criticism of Joomla. Joomla is trying to be a content management system, and it provides the features required for that.)
But Moodle does have a lot of interaction, and with its social constructivist roots, many more people are use the editing interfaces, so we have to care more about those. Templating in interactive interface is much harder than templating a relatively static one. Particularly when you want to include Ajax
to improve usability
code belong to the logic or presentation layer? What about when is making a HTTP request? What about when it is outputting HTML? Does trying to split JS between two layers of the application really help anyone?
So, please stop quoting Joomla as an example. I mean, come on, it does not even seem to offer a forum, just an integration with PHPBB. (How is that themed?) And even I might concede that a forum might be relatively easy to template. What do you need? Forum listing, Thread, Single post and Reply form templates.
Hmm. until you remember that forum posts also have to be output in plain text and HTML emails, both single and digest. And then there are the bits of interface for managing subscribers, and reviewing ratings, ... Is anything easy?
Drupal is a much better comparison, for several reasons. First, Drupal's traditional emphasis on community building, rather than just content management, has a rather Social Constructivist flavour. Second, and probably as a result, there are rather more interactive tools integrated into Drupal.
I do quite like the way that Drupal tries to shove all output through a theme() function - and then there are Drupal theme engines that turn calls to theme() by a developer into the rendering of a template created by a designer. I think it is worth looking into that a bit more to see if we could adapt the idea to Moodle. That might lead to solution that is tolerable to developers, while letting designers do what they want.
When, in my proposals, I talk about turning weblib.php into a class that themes could then override - Well, in Drupal language you would say the theme engine does the overriding, individual themes might not need to bother. Anyway, when I talk about classes and subclasses, you could think of that as trying to take the drupal theme() function and fit it in to Moodle.
(The thing is that the makers of Drupal refuse to use the 'class' keyword (I think because they were trying to come up with an elegant architecture in PHP 4), so they use their strange an mind-bending concept of hooks to effectively re-implement object oriented design without using PHP classes.)
Hmm. I seem to be rambling. What else do I want to say?
Oh yes, of the various difficulties I mentioned with templates in my post above
, the one that worries me most is 4. I really hate duplication in code of whatever form, even it it is template code. Dear template advocates, how do you propose to avoid that?
I know one way of avoiding it. That is what Martin Fowler, in Patterns of Enterprise Application Architecture, calls Two step view
To my mind Moodle comes quite close to implementing that already, although is a rather bizarre way. The first stage is in a rather strange form. It is the sequence of function calls print_header, print_heading, print_box, in whatever PHP script is running. That defines the high-level, structural form of the output. Then phase two is weblib, which turns those function calls into HTML. One of the bizarre things is that we have hard-coded weblib. We don't let themes have any control of what HTML is generated. That is stupid and easy to change. It is the other reason I want to make weblib into a class that theme (engines) can subclass.
And, of course, that view is very much looking through rose-tinted spectacles, because in our step one code we have mixed in direct echoing of strings and HTML tags. Oh, and then there are other bits of code like formslib and tablelib that implement Two step view, but in a different way.
Anyway, I think Two step view is a good pattern for Moodle. To quote Martin Fowler: "If you have a Web application with many pages, you often want a consistent look and organization to the site. ... Two Step View deals with this problem ...". I think that exactly describes the situation in Moodle with all its different modules. But, Two step view means that the overall structure of the content is determined at a higher level than where the HTML is generated, so is not amenable to web designers who want to edit the kind of templates used in many other PHP applications. You have to work at a higher level of abstraction. Which may not be what you want to hear.
I think I really must stop rambling now.