Hi Gustav and Gordon,
Thanks for chipping in in defence of my design decisions Gordon!
I hope that Martin Langhoff and Martin Dougiamas read this thread as
well as they seemed doubtful of my design decision and I do think the
decision was the best for this project. It is possible that I've missed
something in my planning and I'd be very interested if someone could
point this out to me.
Gustav I can understand your concern about the Moodle for Mobiles code.
woven into just about every part of Moodle. And so to get Moodle code
to work on the majority of Japanes mobile phones which really have VERY
limited capabilities is very tough. Japanese mobile phones :
- Older phones choke on a page including images which is more than 2Kbytes!
- The screen is smaller and so we really need the ability to completely rework the user interface.
If Moodle completed seperated it's html output from the program logic
using templates still a lot of modification would need to be done to
the Moodle code to get it working on a Japanese phones because of the
We did get cookieless session support included in the main Moodle
distribution thanks to Martin Dougiamas's interest in this. Still
the code needed to output pages for a Japanese mobile phone involved
significantly reworking the Moodle code. About
the only thing we are doing exactly the same with the Moodle for
Mobiles code is storing stuff in the db in the same way, in the same db
Customscripts provided the best way to do this. We used completely
reworked scripts to generate pages for Japanese mobile phones,
basically I have stripped a lot of stuff from the Moodle code and in
functionality not available on a mobile phone with something else.Other Options
There were two other options that I saw :
- to make massive changes to the Moodle core code put a lot of if switches and so on in the main Moodle code.
- or to filter the output of Moodle to control as much as possible
the output of Moodle by making changes in CFG settings and then
stripping out unwanted tags and manipulating the xhtml output to output
it in a form suitable for mobile phones.
The first way would also be very difficult to maintain. The second
option would not give us enough control over the content and the way we
want to display it on a mobile phone. The second option could also have
been potentially very slow depending on how much manipulation we were
going to try to do. I considered it important that on a mobile phone
with very small page size that pages should be output as quickly as
possible.My plans to track changes in Moodle code
The structure of the code for the Moodle for Mobiles project is very
similar to the structure of the code of Moodle itself. What I plan to
do is to track the Moodle code in CVS and release a version of the code
that will work with the stable version of Moodle 1.6 when it is
released. Barring any major changes in Moodle 1.6 stable after it is
released then the code should work well besides 1.6 for 1.6s life time.
If there are changes that break the Moodle for Mobile code then I will
update the Moodle for Mobile code. There will need to be updates of the
code for at least for every major release of Moodle. I think it makes
sense that I track the changes in Moodle and merge them into the Moodle
for Mobiles code or make the appropriate changes in the Moodle for
Mobiles code and that this will not be that difficult to do.