Hey everyone I am working on implementing AJAX into moodle for some of the course functions (adding drop and drop layout creation etc..) for a Google Summer of Code project. Talking to Martin we have decided to implement a javascript library in moodle officially. I have created a list of all of the major Javascript libraries for this functionality on my wiki page: http://docs.moodle.org/en/Student_projects/AJAX_course_format
I would like to get everyone's feedback on it and any experience they have working with any of these libraries. I have not worked with any of them just gained information from their websites and other resources.
From what I have found I was impressed by mochiKit http://mochikit.com/ but as I said I have not used any of these so there may be some issues that I am overlooking.
Thanks in advance for the feedback and I look forward to helping to improve moodle.
Ed Coyne
Summer of Code 2006 participant.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Nathanael Klassen -
Hi Ed,
I did the integration of script.aculo.us to enable draggable blocks/activities in Moodle. I didn't research all the possible libraries out there, but found script.aculo.us and the Ajax functions in prototype.js made it very simple to add the drag-and-drop features I wanted.
After seeing your post, I tried converting my code to Mochikit, and it was quite simple. The release version of Mochikit does not include the Sortable list function that I use for the draggable blocks, but this feature is in the SVN version. It was ported from script.aculo.us, so I hardly had to change my code at all. The function MochiKit.Sortable.Sortable.create (yes, that's two Sortables), however, isn't quite as neat as the Sortable.create of script.aculo.us. One other difference I noticed is that MochiKit only natively supports GET Ajax calls, while prototype.js allowed POST.
From what I've seen MochiKit can do the same things script.aculo.us can (at least the features I used) and it doesn't have the issue with prototype.js. (Although I'm not sure this is really such a big issue. It only took two small changes to the HTMLeditor code to make it prototype.js compatible.)
Hope this feedback helps.
Nathanael
In reply to Nathanael Klassen
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Ed Coyne -
Well my main problem with the prototype.js incompatibility is that we would be knowingly introducing this bug into the moodle codebase and It could come back to bite us in the future.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Andrew Walker -
Some notes from the panel discussion on JavaScript libraries at the recent @media conference
http://simon.incutio.com/archive/2006/06/26/libraries
I've not really used any of the big libraries mentioned, at the time I was looking around for stuff YUI didn't exist, prototype was still hacking Object.prototype and Dojo seemed too terrifyingly big and complex
Initial impressions of Mochikit look favourable though, from reading the docs their API seems pretty nice and it looks like there's some genuinely useful stuff in there. If I can find some time I might play around recreating chameleon using it.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by David Hicks -
From your Wiki documentation page:
> I was thinking that a javscript "Widget" type system would be great to
> impliment. To allow teachers to enable these widgets for their students to
> use. Perhapes start out with some standard ones, a Calculator, Periodic
> table, dictionary, etc... and allow a easy api for custom class-specific ones.
I've been looking at something quite similar. My plan was to create a simple block that would sit on a course page and give teachers the ability to create their own "widgets" to drop into weg pages, presentation software and whiteboarding applications. Clicking a link on the block takes the user through a wizard-based, step-by-step process to create a widget.
I've been creating Flash-based widgets so far, but there's no reason why they couldn't be HTML/JavaScript, Java applets, PDF, whatever. I've been using Flash because I'm also writing a Flash-based Whiteboard module that it would be easy to be able to drop other Flash-based objects into.
The idea of my widgets is that they are used inside other content (web pages, whiteboard files, etc). I'd like to be able to hook my block up to some kind of reposatory system, so teachers creating content can place their new widgets in a central place for others to use. It looks as though you might be thinking more of widgets that sit on the course page for the pupils to use. However, there must be some sort of cross-over in functionality, and I'm sure we could share some ideas and maybe some code and libraries.
--
David Hicks
> I was thinking that a javscript "Widget" type system would be great to
> impliment. To allow teachers to enable these widgets for their students to
> use. Perhapes start out with some standard ones, a Calculator, Periodic
> table, dictionary, etc... and allow a easy api for custom class-specific ones.
I've been looking at something quite similar. My plan was to create a simple block that would sit on a course page and give teachers the ability to create their own "widgets" to drop into weg pages, presentation software and whiteboarding applications. Clicking a link on the block takes the user through a wizard-based, step-by-step process to create a widget.
I've been creating Flash-based widgets so far, but there's no reason why they couldn't be HTML/JavaScript, Java applets, PDF, whatever. I've been using Flash because I'm also writing a Flash-based Whiteboard module that it would be easy to be able to drop other Flash-based objects into.
The idea of my widgets is that they are used inside other content (web pages, whiteboard files, etc). I'd like to be able to hook my block up to some kind of reposatory system, so teachers creating content can place their new widgets in a central place for others to use. It looks as though you might be thinking more of widgets that sit on the course page for the pupils to use. However, there must be some sort of cross-over in functionality, and I'm sure we could share some ideas and maybe some code and libraries.
--
David Hicks
In reply to David Hicks
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Ed Coyne -
Sounds good, as the page says that is just kind of an idea that would be fun to play with but a different project all together. I like the idea of a central repository though.
Ed
Ed
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Juliette Culver -
Good comparion page!
My personal opinion is that learning curve should be a big deciding factor as a lot of the people who work on Moodle aren't professional hard-core programmers. It's important that the library is easy to use for basic Ajax stuff as well as widgets and that there's good introductory material on using the libary.
I'm actually at a workshop by the guy behind dojo at the moment, and I suspect that the ramp-up for that is going to be a bit steep for most people. From what I've seen of mochikit that looks more promising, though I'd be nervous about a decision being made without people having tried to use it as it'll be difficult to backtrack. On the otherhand I suspect people are starting to write stuff for Moodle using Ajax already so a quick decision would also be good
My personal opinion is that learning curve should be a big deciding factor as a lot of the people who work on Moodle aren't professional hard-core programmers. It's important that the library is easy to use for basic Ajax stuff as well as widgets and that there's good introductory material on using the libary.
I'm actually at a workshop by the guy behind dojo at the moment, and I suspect that the ramp-up for that is going to be a bit steep for most people. From what I've seen of mochikit that looks more promising, though I'd be nervous about a decision being made without people having tried to use it as it'll be difficult to backtrack. On the otherhand I suspect people are starting to write stuff for Moodle using Ajax already so a quick decision would also be good
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Dirk Herr-Hoyman -
+1 for mochikit.
simple is better. don't wait for perfection, go with who are there now and can
continue to move. looks like mochikit is the leader as this moment from that
perspective.
not clear who will be the survivors here in 2-5 years. just pick one now
and worry about the future later. chances are that mochikit will adapt
and cooperate with other JS kits, like DoJo.
simple is better. don't wait for perfection, go with who are there now and can
continue to move. looks like mochikit is the leader as this moment from that
perspective.
not clear who will be the survivors here in 2-5 years. just pick one now
and worry about the future later. chances are that mochikit will adapt
and cooperate with other JS kits, like DoJo.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Urs Hunkler -
Hi Ed,
great approach to discuss the process of library selection here.
The Accordion course format I did with moo.fx which is an extension to the prototype.js. It's fairly easy to work with. The only problem with the htmleditor is solved in Moodle 1.5 and 1.6.
For a recent project I used YUI. The documentation is quite good and it is easy to implement. I had to write some more JavaScript lines than in moo.fx for example, but it looked more flexible.
I found it very fascinating to use the same IDs and CLASSes in the XHTML as hooks to attach behavior on one side with YUI and styling with CSS on the other. The principle is quite similar.
To find a good library with good code is important but only half of the way. The other half is the good documentation and many examples. Many Moodle developers will be using this library and a good documentation and examples will make implementation much easier.
I will look at MochiKit in the next days. When I should decide today I would propose the YUI library due to it's documentation and the very good approach to document it's use with real time examples in a design pattern library. To adopt this idea for Moodle and help the developer community a lot might not be that bad approach.
I am quite sure that the ease of use will be crucial for frequency and quality of AJAX implementation in Moodle.
Urs
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Ed Coyne -
After considering what Juliette and Urs had said and taking another look at the libraries I would have to I agree with them.
I still think that looking at the situation as a programmer the mochiKit looks like the best choice, Its documentation is very clear and concise (to me). But, YUI (and more importantly it's documentation) is designed to be implemented by non-programmers and for this project that may be a more important consideration so I may have to wait for another project to play with mochiKit (I would still be interested in hearing your opinion of it though Urs if you do get time to try it out).
I still think that looking at the situation as a programmer the mochiKit looks like the best choice, Its documentation is very clear and concise (to me). But, YUI (and more importantly it's documentation) is designed to be implemented by non-programmers and for this project that may be a more important consideration so I may have to wait for another project to play with mochiKit (I would still be interested in hearing your opinion of it though Urs if you do get time to try it out).
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Andrew Walker -
I've spent a little time over the last few days playing around with YUI - Here's a few first impressions of the bits I've used (Mostly DOM stuff and events)
Some good things:
1) The way YAHOO.util.Event.addListener allows control over scope for the event handler is incredibly useful. Love this feature
2) Deferred event handler attachment could prove very handy. If you use addListener to attach an event to an element that doesn't exist yet YUI will periodically check for the element becoming available so the event can be attached.
3) The animation API seems pretty slick - I want to try this some more
4) Drag and Drop works really well (DDProxy is really nice) it's also incredibly easy to get a simple example working.
5) Includes some pretty handy cross-browser standardization stuff. Seems to work well cross browser.
Some not quite so good things:
1) There doesn't seem to be anything (as yet) to help take the pain out of creation and deletion of HTML via the DOM.
2) YAHOO.util.Event stores a cache of elements and event handlers so they can be cleaned up at unload, but it doesn't seem to provide easy access to this cache from outside the class itself - it looks like the variables are private with no methods to access them. For example when removing and element from the DOM I might want to look up all the event handlers for that element to unhook them before the element gets removed. It would be nice if I could just take this information from the cache.
3) Typing all that namespace stuff might not be to everyone's taste If this library is being used all across moodle perhaps it could be agreed to include some useful shorthands like
var $ = YAHOO.util.Dom.get;
somewhere that all scripts using the library would have access to?
Generally it's pretty nice to work with, I'm looking forward to trying some of the other parts of the library soon
In reply to Andrew Walker
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Juliette Culver -
I was thinking that it'd really be useful to have some libraries to cover more general Javascript stuff that Javascript doesn't do by itself, not just Ajax, as if people are using Ajax, they're also going to be using more and more Javascript and we're going to get everybody pretty much writing their own mini-libraries. Some of the functions here might at least be a good start.
In reply to Juliette Culver
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Kris Thornley -
good idea! its funny really when you look at the list I have created most of them by nessesity without even thinking about it. A core library would be central point of versioning in the future so people dont go off on thier own paths.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by David Hicks -
> I still think that looking at the situation as a programmer the mochiKit looks
> like the best choice, Its documentation is very clear and concise (to me).
> But, YUI (and more importantly it's documentation) is designed to be
> implemented by non-programmers and for this project that may be a more
> important consideration so I may have to wait for another project to play
> with mochiKit
So, does this mean you've decided that you'll be using YUI in your project? Where will you be placing it within Moodle's file structure? I'm writing some code at the moment that assumes YUI can be found at /lib/YUI, although this is easy enough to change if you decide to park YUI somewhere else (maybe set a config variable to give the path to YUI?). If you've decided on another library then please say as I'm writing bits of Moodle AJAX code now and would like to fit in with whatever you've decided on.
--
David Hicks
> like the best choice, Its documentation is very clear and concise (to me).
> But, YUI (and more importantly it's documentation) is designed to be
> implemented by non-programmers and for this project that may be a more
> important consideration so I may have to wait for another project to play
> with mochiKit
So, does this mean you've decided that you'll be using YUI in your project? Where will you be placing it within Moodle's file structure? I'm writing some code at the moment that assumes YUI can be found at /lib/YUI, although this is easy enough to change if you decide to park YUI somewhere else (maybe set a config variable to give the path to YUI?). If you've decided on another library then please say as I'm writing bits of Moodle AJAX code now and would like to fit in with whatever you've decided on.
--
David Hicks
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Urs Hunkler -
Hi,
after a short look at mochiKit and reading some comparisons mentioned in earlier postings I list my impressions. My point of view was how fast can I find the information needed to implement a special task and how do I get an overview or some ideas how a given task can be done.
- mochiKit looks well structured
- the library documentation looks quite detailed and is therefore complex
- the website does not offer much examples to give ideas how to implement tasks
My impression is that you need to investigate quite a lot to get your projects going.
This experience on one side and reading that mochiKit is one of the best developed and complete JavaScript libraries at the moment on the other side I think one important question should be answered.
- Does YUI lack important parts which are necessary for Moodle which mochiKit has?
- If so, can the GUI features offered in YUI compensate the lack of other parts in their library? Can Moodle developers add those features needed for Moodle?
Urs
In reply to Urs Hunkler
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by David Scotson -
I get the impression that MochiKits goals (e.g. writing a layer on javascript to be more python-like, in depth technical documentation) while laudable, aren't fully compatible with the kind of javascript coding being discussed for Moodle.
Furthermore, while their comprehensive cross-browser unit testing seems the only sane way to proceed, I think Yahoo throwing lots of time, money and manpower at the problem is going to achieve almost the same, especially as they do actually use this library themselves in a variety of projects.
I think either is a good choice and admit to having a soft spot for MochiKit but I think YUI will grow more in the future, just based on branding and corporate support. I also think the YUI stuff has more to offer than just javascript.
Furthermore, while their comprehensive cross-browser unit testing seems the only sane way to proceed, I think Yahoo throwing lots of time, money and manpower at the problem is going to achieve almost the same, especially as they do actually use this library themselves in a variety of projects.
I think either is a good choice and admit to having a soft spot for MochiKit but I think YUI will grow more in the future, just based on branding and corporate support. I also think the YUI stuff has more to offer than just javascript.
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Martin Dougiamas -
Well, it's looking like YUI is the winner, yes?
Let's proceed with that and see how it goes.
Let's proceed with that and see how it goes.
In reply to Martin Dougiamas
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Darren Cooper -
JSON http://json.org/ / http://developer.yahoo.com/common/json.html
is a nice companion for YUI http://developer.yahoo.com/yui/index.html
JSON is available from PECL cvs, however it looks like there is now a PEAR package too: http://pear.php.net/pepr/pepr-proposal-show.php?id=198.
Licensing
http://developer.yahoo.com/yui/index.html#license
http://www.json.org/license.html
Darren
In reply to Martin Dougiamas
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Martín Langhoff -
Go YUI! Sorry I didn't chime in earlier. I've done a similar evaluation recently for a small custom moodle block we've done, and ended up picking YUI too. So we're in the same wavelength 
The only thing I felt bad about was that barely a few days later Google opened up their library and I didn't get a chance to review it (though it does expect a Java backend IIRC).
YUI has a friendly BSD-like license, so we won't have problems with it. Go lib/yui. The only painful thing is that to include it in a reasonable shape within moodle (as lib/yui) you'll want to drop the doco, examples and css bits and pieces.
The only thing I felt bad about was that barely a few days later Google opened up their library and I didn't get a chance to review it (though it does expect a Java backend IIRC).
YUI has a friendly BSD-like license, so we won't have problems with it. Go lib/yui. The only painful thing is that to include it in a reasonable shape within moodle (as lib/yui) you'll want to drop the doco, examples and css bits and pieces.
In reply to Martín Langhoff
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Joan Codina Filba -
In reply to Joan Codina Filba
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Martin Dougiamas -
That project has no code released yet, and was only announced after we started the main one here. I hope they can help Ed out, though!
In reply to Martin Dougiamas
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Joan Codina Filba -
The code is done, I've seen it working, and i hope during next days I'll be able to set up a demo site, where to test and download this and other utilities my students did. The course is finished and students now are in holidays but I think that even if then don't follow ongoing discussions on Moodle.org they are available via e-mail
In reply to Ed Coyne
Re: Summer of Code: Ajax course Project. Javascript library recommendations
by Juliano Vasconcellos -
Ola
I am finishing a project of drag and drop in blocks of Moodle. It is a project that effect.
I would invite you to visit and see this as getting http://julianovasconcellos.com/moodle/
Sorry my English is that I am Brazilian.
I am finishing a project of drag and drop in blocks of Moodle. It is a project that effect.
I would invite you to visit and see this as getting http://julianovasconcellos.com/moodle/
Sorry my English is that I am Brazilian.