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
Nicole
There are some plans for the assignment module which may be summed up in this list (but this is completely irrelevant to the code structure in Moodle core which is what this discussion is about).
Classes are currently used in the import routines. This allows a standard "template" to be set up and then individual specialist import routine(s) to be "plugged" into that template. That looks neat.
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.
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?
mike
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.
I think this is a very good idea, but I 'm not sure if Martin has the time to organize something like this. Maybe if he is interested in doing it we can find a volunteer who will receive directions from Martin and organize the process.
Seasoned, eh? Am I peppery? Salty? Or sweet?
Tom bats his eyes.
(no response necessary...)
Tom bats his eyes.
(no response necessary...)
If you're interested, Martin, I'll volunteer to work with you on the agenda and get something set up.
Jason
Jason
Excuse me if I am way off base here--I do not know anything about code--and I do not even know for sure if you are speaking here about "objects" the way I think--but here is my thought. My courses are all developed around a learning object orientation, and I would particularly like to implement "reusable" or generic objects. I had envisioned a module similar to making a quiz, except you would be making a course, and each object could be chosen from one central repository, similar to being able to choose questions from different categories in the quiz module in order to build a new quiz. I'm thinking of it as kind of an online "Instructor's Resources/Manual". --So, similar to adding questions to a quiz category, you would upload files to an object category...(same code/different file type?)
I would suggest looking to the OKI as a source of OO inspiration. Being Java based, they have to implement an object model, and there are some very smart MIT people working on the service definitions. A PHP version of their reference implementations might not be a bad thing.
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.
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.
Some thoughts on an object model
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:
Authorization
Authentication
Logging
SQL Manager
Filing
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:
Module manager
User manager
Session Manager (this may belong in the level below, I'm undecided)
Messaging Service
DMS
Portal Manager
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 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:
Authorization
Authentication
Logging
SQL Manager
Filing
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:
Module manager
User manager
Session Manager (this may belong in the level below, I'm undecided)
Messaging Service
DMS
Portal Manager
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.
Jason,
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!
Jon
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!
Jon
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:
- mod/mod.class.php:
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. - mod/NEWMODULE/NEWMODULE.class.zip:
A templated version of what a new module would do to extend the main class. - mod/NEWMODULE/(CLASS)lib.php:
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. - mod/wiki2/*:
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.
mike
Tnx Mike,
I look forward trying your template - just not sure where it needs to go and what to do with it 
J
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.
mike
Nice start Mike. There are some good ideas here.
I'm assuming that we will be waiting for PHP5 in order to develop the new object model? If we're going to take the time to refactor the code (which is a risky undertaking in my mind), we should take advantage of the new features of 5, rather than the kludge in 4.
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.
http://www.sitepoint.com/article/coming-soon-webserver-near/5
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.
Jason
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.
http://www.sitepoint.com/article/coming-soon-webserver-near/5
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.
Jason
I have been working with PHP 5 on another project, and it is looking very nice. The object implementation is very java-like. There is not a huge difference from the programmer's point of view (excepting perhaps the scope improvements) but I understand it is completely rewritten under the skin.
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
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
Hey - we could always rewrite it as a Java webapp!
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?
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?
Performance will be very important, in fact I will be looking to improve performance as much as possible. Moodle needs to be able to run well on shared web hosts - it's a major advantage over Java-based systems (for example).
You don't like Java, do you? 
Howard thoughtfully said:
>>
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.
David
>>
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.
David
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.
True, it could be an issue.
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
David
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
David
Which brings us nicely back round to templates. I think we all know that this is the next big step in Moodle. One good thing that can be learned from the Java community (there must be something ) is to separate out the functionality of the system. The code that displays stuff should not be mixed in with the 'logic' of the system. This then makes issues like cacheing relatively straightforward.
Templates and CSS are my urgent priority afer 1.3. Everything else development-wise will have to wait until that is done.
Keep tossing around great ideas about the class design though - this will be very useful reference later.
Keep tossing around great ideas about the class design though - this will be very useful reference later.
Book recommendation.....
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
New Riders
ISBN 0-73571-245-X
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
New Riders
ISBN 0-73571-245-X
Thanks for that book recommendation. I just bought a copy and am thoroughly enjoying it. First on my daily train journey (two times an hour) and now behind my laptop doing project one.
Great stuff!
Great stuff!
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.
Hi everyone,
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?
Jon
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?
Jon
Hi Jon,
"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!!!
Keep in mind that PHP 5 is only in RC2. No responsible ISP would install it for their clients until at least the official 5.0 release.
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 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.
Of course that was what I had in mind, too. Or does anyone here think that Moodle 2.0 will be ready for release before 2005? (OK, maybe a little before )
)
Note that I HAVE to ship a Moodle with new templates a lot sooner than that, so I will be happy to leave out refactoring until the templates are in place.
I didn't know that. Then maybe refactoring should indeed come after the templates. But at least we should reach some kind of general agreement first, so that the templates can be done with the future refactoring in mind.
Moodle 1.x currently is compatible from 4.1 and later. 4.1 is several years old now but you'd be surprised how many sites I come across where that is still used.
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:
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.
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.
PHP5 obviously represents a step change in support for objects in PHP. Its as significant a step as that between PHP3 and 4. I think it comes down to deciding if Moodle should embrace object orientation fully. If that is so, I believe that the addition features of 5 are necessary to do the job 'right'.
Having said all that the system requirements of Moodle are clearly a vital consideration.
Its difficult!
Having said all that the system requirements of Moodle are clearly a vital consideration.
Its difficult!
Martin, thank you so much for insisting on keeping Moodle code simple to understand for the layman 
.
.
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?
mike
Well its at RC2 at the moment and is reasonably stable. Yes, there will still be bugs of course.
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
http://www.php.net/zend-engine-2.php
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
http://www.php.net/zend-engine-2.php
Yes, I wasn't talking about PHP 5 right here right now. Although I believe that even in RC2, it would be reliable enough to do development (not production) on.
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.
Jon
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.
Jon
I'm going to compare PHP to Java again, which is getting embarrassing. FWIW I have some serious issues with Java, mainly due to the crazy user community that insists on making things 'clever' but an order of magnitude harder than they need to be.
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?
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?
I think that everybody who used Java really welcomes the direction PHP5 is taking
Nobody here mention one new important OOP feature - the interfaces. Proper use of interfaces makes the resulting system more open and extensible.
Nobody here mention one new important OOP feature - the interfaces. Proper use of interfaces makes the resulting system more open and extensible.
Hi Howard,
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.
Jon
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.
Jon
I think we should take a serious look at PHP MVC frameworks. If you are not familiar with this concept then a quick explanation:
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...
www.mojavi.org
www.phpmvc.net
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...
www.mojavi.org
www.phpmvc.net
This looks interesting Howard. I hadn't heard of this design pattern (God, I'm a dinosaur) yet. It warrants a further look.
mike
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:
http://minnow.cc.gatech.edu/squeak/1
Old tutorial: how to use MVC:
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
and:
http://minnow.cc.gatech.edu/squeak/1767
What I like very much is their built in class browser:
http://www.cc.gatech.edu/classes/AY2000/cs2803ab_fall/BrowserBasics.html
( They even have one online browser, I cannot find it that quick.)
Yes I agree - but is not ORB a fantastically complicated object communication protocol? AFAIK it has effectively superseded by web services. Mmm... there's one for a rainy day - a SOAP server built into Moodle! That would enable simple clients to be developed that access the capabilities (and data) of the moodle server.
Ok, I'll shut up now
Ok, I'll shut up now
I only have old books, so what is the news?
(As user I like the use case driven design approach, Doug Rosenberg from ICONIX)
(As user I like the use case driven design approach, Doug Rosenberg from ICONIX)
This is a good place to start...
http://www.onlamp.com/pub/a/php/2003/07/03/php_amazon_soap.html
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
http://www.onlamp.com/pub/a/php/2003/07/03/php_amazon_soap.html
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
My +1 vote for some MVC. Having each part (model, view, controller) separated will improve modularity and modifications, sure !!
Although performance could be a problem if we try to be too much strict with the model (from my experience with Java).
Ciao
Although performance could be a problem if we try to be too much strict with the model (from my experience with Java).
Ciao
Another fine MVC-esque framework is Seagull. I have used seagull a bit, and the nice thing is the practical approach of the author(s). They are not religious about strict conformance to the design pattern where it doesn't make sense in PHP. Performance is very important.
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.
John
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.
John
Hey Howard.
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.
Thanks
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.
Thanks
Hi Jason,
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?
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?
Another MVC framework is Phrame
http://sourceforge.net/projects/phrame
They are a much higher release number (2.1 rc1) than php mvc (what the actually means I'm not sure).
http://sourceforge.net/projects/phrame
They are a much higher release number (2.1 rc1) than php mvc (what the actually means I'm not sure).
Martin - what ideas do you have in your head for Moodle 2? Are you contemplating biting the bullet and doing a complete ground-up rewrite, or is this more a case of running over the existing code making generalised improvements?
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?
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?