redredred

After being inspired by the recent fullcalendar (month based) plugin by Adam Shaw, I decided to port a weekly calendar i’ve been working on into a proper jquery plugin. Until a couple of days ago it was practically impossible to use this calendar functionality outside of it’s host application but now it should be simple to integrate it into any jquery-ui based application.

I made a conscious decision to base the week calendar api off the fullcalendar plugin, using the same event names where it makes sense and most importantly to use an identical data format. The idea being that the two plugins could co-exist utilising an identical data source and similar programming style.

You can see the full details of the plugin on the project page but to summarise the feature set:

• Display of calendar events within a weekly grid
• Calendar events can be supplied as an array, url or function returning json
• Calendar events can be dragged, dropped and resized
• Lots of callbacks for customizing the way events are rendered plus callbacks for drag, drop, resize, mouseover, click etc
• Automatically scrolls to current time
• Extend the core calendar event data structure with your own data
• Compatible with FullCalendar data sources with very similar events

jquery week calendar

At this stage there is only a basic demo in place but when time permits i’ll add a series of demos that help to show how you might extend it to fit your application requirements such as:

• Modification of rendered events based on custom data / logic
• Using jquery ui dialog for creating and editing events
• Using some of the other events to provide a better experience

This plugin is an early release and i’d expect follow up revisions to be coming out very soon. Any feedback, bug reports etc would be welcome.

Check out the full documentation and demo here

I came across an interesting bug today with IE7. Actually, no not interesting, frustrating is a better word to describe it. I had a random appearance of a horizontal scrollbar within a div that has a fixed height set in javascript and overflow auto to achieve a viewport style interface.  The correct  behaviour, the one exhibited in all other browsers, was to add a vertical scrollbar to the fixed height div and not to add a horizontal scrollbar. What IE7 appeared to be doing was not compensating for the vertical scrollbar and adding a horizontal scrollbar with a scroll amount of the vertical scrollbar width.

IE7 horizontal scrollbar being forced by width of vertical scrollbar

Following ?

Ok, now some searching on the web came up with a lot of mentions of this kind of behaviour in different forms and the common fix seems to be using the following css attributes:

overflow-x: hidden;
overflow-y: auto;

Unfortunately for me this didn’t work. I tried all sorts of variations like forcing widths and a whole bunch of irrational, voodoo style css attributes in the hope that i’d happen across the right combination that would slap IE into submission. Nothing!

Some other behaviour that i’d been thinking was odd but hadn’t given lot of thought to yet was:

1. Scrolling the scrollbar to the right would cause it to disappear.
2. Elements such as text, fields etc that appeared underneath the scrollbar showed through

underlying elements showing through scrollbar

I tried using javascript to simulate a scroll to the right on load – something that made me cringe but it was worth a try. No luck still.

Finally, it occurred to me that the answer could be in the second of the observations described above. Ahaaaa! What if I give the element with the desired vertical scrolling a background color. Given that the elements within the scrollable dive are showing through, maybe giving the element a background color would show through as well and effectively hide the scrollbar. At that stage the element background was transparent so if I give it a white background which is was gaining from an underlying parent element that should cover this rogue scrollbar.  And that was that, the scrollbar is gone.

I immediately tried to describe my frustrations to my girlfriend of one more day of my life being wasted due to Internet Explorer and was somewhat unsatisfied with her lack of understanding.  I’m not sure what i’d expected from her but she definitely appeared to be more interested in the interview with Viggo Mortensen on the television – who’d have guessed!!

Writing efficient Javascript doesn’t really seem to matter too much while you are trying to make something work. Mostly people don’t take Javascript too seriously and more often than not just hack something together that works regardless of other considerations… or maybe that’s just me

When you are writing Javascript that will be re-used and is likely to be called on a page multiple times, and that page grows and grows, suddenly you can find yourself with a web page which performs like a dog and most likely leaks to boot. I have had a few experiences like this and after writing the validation framework for the Spring Layout tags I have had an opportunity to revise my style and I thought that I would articulate a few principles here that have greatly aided me in writing efficient Javascript.

1. When accessing form variables, use the form field collection rather than the DOM. It is tempting to just use the prototype $ function all the time but it is extremely inefficient compared to getting the field from the forms field collection or better still getting a reference from the event source.
2. Use methods like addEvent(…) sparingly. Most people, these days add Javascript events dynamically using some wrapper to genericize the method for IE and Mozilla. This is a good practice, but if a lot of methods are going to be added to an event it can become quite heavy weight. Consider aggregating functions whenever possible to make this more efficient.
3. Always declare a local variable for calculated values or functions like document.forms[0] which are going to be re-used in a function. Javascript does very little optimization for you and particularly in loops it can become very expensive re-calling functions or accessing data members over and over so you need to declare a local variable using the var keyword for anything you are going to re-use.
4. Loops which are implemented ineficiently in Javascript can be very expensive indeed. A number of basic principles should be employed when writing loops see this article for an in depth analysis but I will sum up the major points here.

• Minimize if statements within a loop, switch statements are far more efficient in Javascript however if you must use if statements combine them whenever possible to reduce the number of distinct statements as every if must be tested even if an earlier one evaluates to true.
• Loop backward whenever practicable using loops iterating on index– is surprisingl much more efficient than index++ and –index is even more efficient particularly when you use a do/while loop rather than a for loop (the figures for the speed difference are staggering, check the link above)
• Obviously, remove invariant code from the loop, anything which can be calculated once before the loop should be.

I will keep adding to this entry as I have the time. I encourage others who have tips on this topic to post them here as comments.

A while ago we were implementing a large, web based, data gathering application for a government department. The application required quite complicated cross field validation and very specific visual feedback mechanisms which had to be live on the page whenever possible. We had already been developing a tag library to extend the bind tags provided out of the box in Spring MVC so we decided to bite the bullet and integrate validation into these tags (I will write more on this project in other entries).

We made extensive use of the Prototype and Behaviour Javascript libraries to assist in cross browser compatibility and to try and keep as much Javascript event code off the page as possible. We soon began to see performance problems in IE. For quite a wile we couldn’t pin down what was making this problem occur as it seemed quite intermittent, but eventually we pinned it down to browsers which had been open on our application for extended lengths of time without being closed and re-opened.

Checking the memory footprint of IE we quickly noted that it’s size was growing at the rate of almost .5 mb per page load. After a fair bit of analysis we discovered a tool called Drip which we found invaluable in tracking down and plugging the leaks.

Two main issues are at the core of memory leaks in IE and the drip link above provides links to sites which discuss both of them.
1. Closures: Briefly closures occur when functions reference variables scoped at higher levels.
2.Event listeners with references to the DOM: Briefly this causes self referencing islands which IE is unable to garbage collect.

Issue number 2 is fixed relatively easy by the event cache javascript a link to which can be found on the drip page I have already linked. The problem of closures is far less difficult to fix but can easily be detected using the drip tool.

There are two possible remedies once you find closures which are leaking memory. The first is to alter your code to remove them altogether. Unfortunately this is not always easy to do or can involve extremely verbose workarounds. In instances where you are attaching an anonymous function to an element (something that we often do when using Behaviour) you will almost invariably create a closure which will leak in IE. We found this closure script to work extremely efficiently in removing these leaks in IE.