I think a great idea would be editing the assignment module a lot. It would be great to save on file transfers if the student could have the option of typing their assignment or uploading one. This will also help in the case of different file formats with assignments. I have had several problems with students trying to submit weird formats that I couldn't read.
Also make it simpler to view assignment submissions and maybe have something on the front page of the course saying which assignments need yet be graded.
Just some ideas
The comments within these routines talk about having a similar structure for the export routines. Having done a bit a work in this area recently, I not convinced that we need to actually follow through that sort of class structure to the export side for modules. At the module level I think it may be enough for them to just export in their own single format (probably very similar to the Backup XML format). This is what the Glossary module does now.
For example in the Lesson module I'm not sure there's much point in writing both a XML=like export filter and, say, a GIFT export filter. So long as there's an import filter to read the Lesson XLM-like stuff (available to any module which wants to read in Lesson stuff), why ever export a Lesson in say GIFT format. It just adds a layer of confusion for the teacher doing the exporting (the Glossary module does not ask what format to export in, it just does it - great!). (Aside. It would be nice if the import filter mechanism could be made a bit more intelligent and get it to work out which actual filter to use.)
I suspect if we ever want to export to other VMEs that will be at a course level. And that might well utilise a class.
Hi Martin -
Do you have a top-level class structure in mind? Or should we start suggesting class models without that?
I would like to suggest Martin schedule a "Virtual Moodle Developers Conference" to get all the Moodle wonks in one place, and discuss the original premise of this forum. My Elluminate room (like LearningTimes) should be available soon and I offer it for use. Martin can invite who he wishes, set the agenda and ask each attendee in advance to prepare a short presentation of their ideas and arguments. It might be advisable to ask a few seasoned teacher types (eg. Tom Murdock etc.) to sit in and listen, and then solicit ideas at the end of the session from these folks. If this experiment works, we can hold such conferences at regular intervals with pre-defined topics.
Tom bats his eyes.
(no response necessary...)
An additional advantage is the future potential of interoperation with Sakai or other OKI based CMS projects.
At the very least, we could use it as a base to start our planning.
I've been reading over the OKI specs and they've got some interesting ideas. I don't think we need to copy them explicitly but we can use it as a starting point for our model.
I've attached a graphic as a starting model. I'm not wedded to this by any stretch, but it's easier to have a conversation around something concrete.
At the bottom we have the file system, the database and the database driver (abodb). These are systems that are out of our hands and rightly so.
Martin and the core developers have done an excellent job of creating an API that is easy to use. The maintenance can get a bit squirrelly as there is some natural conceptual blending and not a lot of seperation between interface and logic.
So the core set of objects presents a set of services that every piece of the system can and will need to use. My core list of services includes:
Above this, we begin to build Moodle interfaces and logic. Most of the services on the next level present administrative interfaces but not directly to the instructor and students. These services and API's are also useful to other systems and services:
Session Manager (this may belong in the level below, I'm undecided)
Above all of this lies the Course Manager object. This object provides a wrapper for each course, stores and manages the course settings. This presents an interface for instructors and admins
Above the course manager are the individual modules and functions that comprise a course. The list includes all current modules plus the gradebook. I would move the gradebook to this level to modularize it further and give the user more options around management.
I 've read this post on the run and there are many things about it that I like. I want to expand it some more and give more details on a few subjects, possibly create a new graph too, but no time right now...
Still, very nice post!
Just for fun, I reimplemented the Moodle module interface (NEWMODULE template) in OOP. I have attached it here, along with a simple example of its use.
There are a number of files:
Contains the base class interface defintions for any Moodle module. All modules would be required to extend this class, and implement the necessary interface methods.
A templated version of what a new module would do to extend the main class.
A temporary replacement for the current Moodle module lib.php, implemented by all Moodle modules. This replacement acts as a go-between, between the current module interface and the OOP method. It basically does the work of creating the module object and calling the methods. Ideally these functions would occur at a higher level, where the current library functions are called for the modules.
This directory contains a sample, real implementation of the above using the wiki module. It contains a wiki class file derived from the module class and a replacement library file.
I don't necessarily believe we should adopt this right away (and I've kind of jumped ahead of any actual design), but I wanted to see how much easier it might be to build a module if there were classes already in place. So far, I like it.
I look forward trying your template - just not sure where it needs to go and what to do with it
Sorry, I was a little vague...
It's intended as a coding demo of how we could move towards class based code (OOP) for module add-ons. This code replaces the 'NEWMODULE' template currently used to create modules. The example I supplied (wiki) is a small subset of the wiki module I've been working on.
I'm not sure if you should try to use it as is; the example module isn't a complete module. I am going to redo the Wiki module this way - I can let you know when its complete. Otherwise, I'd just use this as a coding example to review.
For a nice overview of what's coming in PHP5, take a look at this article. I've started the link on page 5 where he starts talking about objects.
There are two concerns we need to address as we move forward with an object design:
1) AutoLoading - This will be a must for performance. When PHP loads a page, it will need to load all the classes included, which will be a big performance hit. AutoLoading allows us to specify that a class is only loaded when it's needed. We will need to define a coding standard that will enable us to utilize this.
2) OOP performance - There is a bit of overhead associated with objects. Some base comparisons early on indicated that PHP classes were significantly slower than the same code implemented as a function. I'm not sure how this is going to work in 5, but it's something we need to keep in mind. I'd hate to trade off code maintainability for system performance.
We also need to address the learning curve issue. Currently, the simplicity of the core code and the functional programming style make it easy to contribute. Adopting an OOP frame of reference may be difficult for new programmers to get up to speed.... just something to consider.
To risk a flaming, I actually am really looking forward to a properly thought out object model if it indeed comes about. I believe that well written classes vastly contribute to the clarity and (effective) documentation of code. Look at the new blocks code for example - I think its much easier to understand than some of the existing code - I wish modules where implemented similarly. I am don't really agree that the present style is particularly simple (although much better then most/many PHP projects).
On the performance point, its kinda the Java thing all over again. In some respects its an attitude of mind. Hardware is cheap these days compared to programmer's time, and I think we'll see a big boost in the final versions of PHP5.
The other worry of course, is how quickly the hosting people will move to 5 - could be a tricky one!
Hey - we could always rewrite it as a Java webapp!
BTW... nothing to do with this thread. but lets get templates and (proper) CSS implemented this time around
That's not funny!
Actually, the templates and CSS implementations will have a lot to do with this thread. We need to ensure that every object that presents a user interface uses templates as part of our developer standards...
Do you know of any performance metrics for PHP 5 objects yet?
The other worry of course, is how quickly the hosting people will move to 5 - could be a tricky one!
Not really a problem as you can run any version of PHP that you like as a CGI application. My hosting company even provides step by step instructions for compiling your own version of PHP, with whatever modules you need.
You can even run different versions on the same web site.
Not really a problem as you can run any version of PHP that you like as a CGI application.
Hmm... let's see, 250 concurrent moodlers making say 2-3 CGI calls every minute or so.... Does that sound like a good idea. Been awhile since I looked closely at what each instance of CGI does for performance on a modern server.
Perhaps then it is time to consider some form of page cache like Typo3 uses.
When you think of it, most of your moodle pages are static, so can be saved in HTML rather that regenerated from the PHP code each time they are displayed. I am not sure how Typo3 handles this but it works very well.
Anyway, I am straying totally of topic here so I had better stop
Keep tossing around great ideas about the class design though - this will be very useful reference later.
Coming from the background of being a programmer I thought I understood CSS and that it was easy. Then I read this on a long train journey, and it was a complete revelation. Meyer is very much a CSS guru; he takes the view from the design of the page rather than just looking at CSS as a language. Highly recommended!
Eric Meyer on CSS
Eric A Meyer 2003
Very interesting discussion. From a user perspective, I does not think the use of PHP5 a very good idea. For sure, one of the strongest feature of Moodle is it's ability to run on the most part of APS platforms, even on some simple hosting account. I think this allow for wide spread of the solution, easier install, and scalability when you need it. Hosting company will certain upgrade to PHP5 but who can guarantee they will do as soon as PHP5 will be released?
Also, from a user persepctive, I feel more interesting the implementation of templates, thus separating application layer and presentation layer.
I 've finally taken the time to view Mike's OO sample. This, in turn, started a lot of worker threads in my head , but I realized that before saying anything, the million dollar question is: "Will Moodle 2.0 require PHP 5 to work?"
To clarify things a bit, I should say that my personal view is pro-PHP5. It just offers too many useful improvements to be disregarded. Also, working with PHP5 is a very much "look to the future"-style approach, which appeals a lot to me. I don't think there will be problems with hosting Moodle, since PHP is PHP, and frankly IMO all serious hosting providers will install it as soon as it reaches release. Noone would like to be the one without PHP 5 support. The only catch is the "security/stability" issue, but I don't think there will be problems here. PHP "bugged" me to death only once, and that was when I was trying to do some fancy stuff using "unstable" extensions (object aggregation, to be precise).
Of course, we could build a framework that detects the version of PHP and loads the classes for ver 4 or 5 accordingly, but this would be duplication of lots of work, and the necessary human resources do not exist.
Martin, what's your view on the PHP 5 subject?
"Should Moodle 2.0 require PHP 5 to work?"
Lots of moodle system are installed on hosted servers. The admin has no chance to add php 5.0 to the time the provider does it. Most provider don't use today php 5.
When i looked for an os learning system i decided against ilias, because ilias used php version in developed and my provider doesn't support new features of php.
Also. No php 5 now!!!
I imagine that a refactoring of this magnitude is going to take some time. By the time we're ready to release, PHP 5 should be out, stable and working it's way up the adoption curve.
I would like to see the 1.x tree maintained for a while as an independent branch for people who just want to use the features developed so far, so that Moodle 1.x will always be an option for people stuck on PHP 4.
This means that Moodle 2.0 DOES have the opportunity to use PHP5 features, but I would want to be really careful that these are:
- really advantageous features and not just "cool"
- still simple enough for an average science teacher to be able to find their way around and make a small hack where necessary
In Moodle 1.x I deliberately chose not to use full object classes for these reasons. In my view, the "mod/xx" directory is the class, and each script in there is like a method. I still think this was a good choice, and has got Moodle so far.
However, now Moodle is growing beyond the hobby project it was back then and I can totally see the benefits of a more formal and encapsulated approach.
I would just like to temper new designs with simplicity and hackability. I hate obfuscation even it saves a few lines ... I like my code to read as closely as possible to English sentences.
Having said all that the system requirements of Moodle are clearly a vital consideration.
Hi Jon -
I haven't updated to PHP 5 yet. I figured it would still be buggy. Is it not?
I think PHP 5 may be slow to adopt across the servers out there, so it would probably be safer to design using PHP 4 object code that doesn't depend on any of the PHP 5 specific elements.
I took a quick look at the PHP 5 spec. Other that 'static methods' what have they introduced new that wouldn't work under 4?
There are huge changes in the object model, it has been pulled right up to the level of "proper" object oriented languages. The exception handling alone is a very welcome addition, and of course abstract classes......
Anyway, from the horse's mouth, if you will
The changes in the object model were exactly what makes me want 5. Exception handling is nice, but their use has fanatical opponents, too. It's one of these things that is definitely good in some situations, and definitely bad in others (for example, when writing software libraries, you must be VERY VERY careful that exceptions do not propagate out of your library unless this is clearly documented, and even then for "simple" operations many times it's better to not propagate entirely). This is something that can only be learned with experience. Thus, being a controversial subject even among professionals, I think that exceptions should be left alone in Moodle.
Anyway, I digress...
My point is that when I first learned Java I was horrified by the way it forces exception handling upon you - for those that don't know, in Java if something can possibly go wrong you must do *something* about it (even if that's to say that you are going to do nothing) or the program doesn't compile.
However, after a few days of throwing things at the computer I realised that I was actually writing better and more reliable code - and we could all do with some of that. I hope Martin won't mind me saying this, but Moodle is full of places where potential exceptions are unhandled, you wouldn't get away with that in Java.
Its the difference between "it'll do" and "its right". And don't get me wrong here, I am not stirring trouble (not this time anyway) - "it'll do" is often good enough. I just (a) understand why the average PHP programmer will be horrified and (b) think we should consider the usefulness of exception handling in Moodle. I think it will result in a better product - just my opinion!
PS: Re your comments on software libraries - surely this is the *very* place where good exception handling and documentation thereof is vital? If something goes wrong the library should either handle it elegantly or pass it back to the caller - doing nothing is a bug looking for a place to happen, and a confusing bug at that.
PPS: Anybody noticed that Adodb now has PHP5 exception support built in?
Nobody here mention one new important OOP feature - the interfaces. Proper use of interfaces makes the resulting system more open and extensible.
The part about writing better and more reliable code is valid, up to a point. For example, even though I haven't seen exactly how ADOdb implements PHP5 exception support, the documentation implies that if you do not include adodb-exceptions.inc.php, then no exceptions will be thrown. Which is a good thing, because otherwise it would force you to upgrade your code with exception handling, i.e. break your application. Not a good thing.
You have to realize that not everyone around here is an experienced programmer. Even though IMO OOP is slowly becoming a topic known to anyone who has dabbled with programming (much like Fortran was 25 years ago) and thus should be used, as OOP-ignorant people increasingly become a minority, I couldn't say the same thing about exceptions. We shouldn't impose an exception-enabled framework upon them, since that would greatly decrease the number of people able to contribute to Moodle. Optional, yes; obligatory, no.
Don't get me wrong; I do agree with you that exceptions are generally a good tool and properly used make more "correct" and "robust" code. But this is not a home project, where I would "do it right" and go to extreme lengths of clever algorithm optimization to squeeze a 2% performance increase out of the code. This is Moodle, and you don't want to make it so hard that only professionals can understand it. Professionals, by definition, code for money.
Also, my comment about software libraries was meaning to say that exceptions should be extremely carefully coded, if used inside a library. Remember that someone might use your library during a process. If your library fails to do something and throws an exception, you have just forced the programmer to account for this fact or risk leaving his program in an unknown state. That's why libraries should provide at least the "basic" exception safety guarantee, and in many places the strong one.
For a very brief reference on the three types of exception-safety guarantees, plus a paragraph that pretty much sums up what I 've been trying to say (read especially the first two sentences) by the man himelf can be found at http://www.awprofessional.com/articles/article.asp?p=21084&seqNum=5, and the whole article is a nice read if you have the time.
This is nicked from Java (again), but the idea is to split the system into three discrete parts Model-View-Controller. These are roughly as follows...
Controller - a single entry point for ALL pages. This then decides, using a configuration file (usually in XML) what to do next according to the user input. It will also to a greater or lesser extent handle things like authentication and input verification.
Model - The actual program logic, and database interaction. The important point is that this is kept apart from the View which is...
View - The bit that displays the pages. The controller calls the right Model class to figure out what to display and the View displays it.
These frameworks typically include a lot of stuff that you nearly always need in a web application as part of the deal. This all makes it very easy to understand how a program hangs together. There is only ever one entry point, and the high level logic is all described in one config file. Stuff like on-demand class loading is usually built in and you don't have to worry about it.
The down side? Well its a learning curve and getting a projects started is a pain, as loads of stuff has to be set up and got right before anything works at all.
The are a number of implementations in PHP. Here are a couple, but phpmvc looks the better bet...
This looks interesting Howard. I hadn't heard of this design pattern (God, I'm a dinosaur) yet. It warrants a further look.
In general the goal is finding (design-)patterns.
- MVC is one "group",
- ORB is another (Object Request Broker)
MVC itself had it's roots in Smalltak 80 (Adele Goldberg and ..?) a remake is Squeak:
Old tutorial: how to use MVC:
What I like very much is their built in class browser:
( They even have one online browser, I cannot find it that quick.)
Ok, I'll shut up now
(As user I like the use case driven design approach, Doug Rosenberg from ICONIX)
its good stuff regardless of Moodle, it surprised me what you can do quite easily accessing available information from around the web.
For example you could set up a bibliography and automatically pull the (say) picture of the book off Amazon's site by hitting off their SOAP server using PHP.
However, we are getting way, way off topic now
Although performance could be a problem if we try to be too much strict with the model (from my experience with Java).
Most of these frameworks are moving targets (hence the low version numbers). Also, I don't know if any of these are specifically targeting PHP5 yet. Seagull is definitely holding off for a while on PHP5 and it will probably be a major version rev/rewrite deal.
I've never designed a large scale MVC system before. I understand it conceptually, but I'm wondering how it works when you have a modular system like Moodle...
Does each module implement it's own complete MVC model? Or is there always one main controller and each component implements its own model and view?
I'm trying to visualize how an MVC architecture would fit with something like the conceptual object diagram I created above. Once I grok that, then I'll really be ready to start designing some aspects of this.
No, there is only one controller - that's the point/challenge/restriction.
The usual method (ie, in Struts) is for each 'module' to be otherwise self contained. That is, it has its own controller configuration file. The MVC framework has the ability (usually) to integrate the diverse configuration data at run-time.
Does this help?
They are a much higher release number (2.1 rc1) than php mvc (what the actually means I'm not sure).
There is an old saying (which I have found to be true I'm afraid) that a software project is never right until you have completely rewritten it for the third time. I suspect you didn't know what Moodle was going to look like when you laid down the framework for the current version. Would you have done it the same way if you know then what you know now?