Posts made by David Scotson

The only visible difference for me (since I edited out the 'loading' messages) is that the links don't jump me to the top of the page (which could be fixed in the HTML version too by adding the appropriate #anchor to the link) and a snappier response time because only the data that changes is being fetched from the server and redrawn on screen.

The general approach with YUI in Moodle will (hopefully) be to make things generally snappier and more responsive, while reducing server load and not impairing accessibility. This calendar mod is a small but important first step in that direction though it probably only rates a 'neat' rather than a 'wow-wee' on the cool-o-meter (and even then you'd have to be a geek like me to be impressed).

Having said that, it would be rather slick if the current month slid to the left and the next month slid in from the right to replace it (and similarly from the left for the previous month). Any YUI experts know if that's possible? It would probably help the user understand what's happening too.

Regarding overlib.js and the Calendar pop-ups, I personally would be happy to see it removed completely and replaced with a simple text title attribute to be displayed by the browser.

YUI does include a simple 'tooltip' class that could be extended, as well as the more general 'overlay' class that can be used for all sorts of pop-ups but I'm just not sure how usable/accessible it is to have little tooltips popping up that contain links. And at the moment it's yet another strange wrinkle to deal with when themeing.

Maybe YUI could be used to hide and show a list of all events for the month and filter by date/type but on the other hand maybe just a clickable link that takes you to a simple clear HTML page with the events for that day would be simpler and more usable as well as more accessible?

However I must admit I'm not a big user of the calendar and maybe people would be outraged at having this vital feature removed. In that case a YUI rewrite would certainly be the best way forward.

There's a file called lib/javascript.php which controls the javascript includes in the head section of your Moodle pages.

You'll find lines like:

<script language="JavaScript" type="text/javascript" src="<?php echo $CFG->httpswwwroot ?>/lib/overlib.js"></script>

which you can copy and change to include the required files (listed in a post above) e.g.

<script language="JavaScript" type="text/javascript" src="<?php echo $CFG->httpswwwroot ?>/lib/yui/yahoo/yahoo.js"></script>

(ignore the extra X added by Moodle for security reasons)

As Jan mentions there are 'compressed' or 'minified' versions of each file called whatever-min.js which are used in production to reduce download times. If you want to play about with the javascript then I'd stick with the standard versions for the time being.

I'm not sure how YUI is going to be plumbed into Moodle. Ideally you only want the parts that are used loaded, but you don't really want to go the route taken with CSS where different files are munged together as that would affect caching. Ideally you want a way to request that standard javascript library file x be linked from the header (but not add it twice if it is already requested) but also add random javascript, e.g. what is currently stashed in a script tag within the AJAX calendar block, too rather than have it inline. From what Jan says about javascript.php files within blocks the latter is possible but not the former.

Within that framework it might be cool if turning on Moodle's debug mode swapped out the minimised javascript for the more verbose ones (I think some have actual 'debug' versions too)

Hi,

I tried out your calendar and it's very cool, this should certainly replace the current calendar.

For anyone else trying it out, to get it working I needed to add:

/lib/yui/yahoo/yahoo.js
/lib/yui/event/event.js
/lib/yui/dom/dom.js
/lib/yui/connection/connection.js

to lib/javascript.php (I assume this will be done automatically once Moodle uses more of YUI?)

One suggestions would be to leave the current calendar in place right up until it gets replaced. Otherwise, for me at least, it makes the calendar 'wobble' as the column shrinks and then grows again as the content changes. (Maybe just change the clicked link to a 'throbber' to show something is happening.)