Recomended Development Platform
Developing widgets does not need as much as developing Java back end services for Sakai. If your widget is going to modify data on a Sakai server then you will need to have a Sakai server accessible to your machine, but you will not need to have it running on your machine or have access to its disk. Widgets work in the client so you just need a way of loading them into a browser. Initially this can be direct from the File System, but later you can use an instance of Apache to proxy through to the Sakai server. I will explain how to do this later.
To develop Sakai Widgets you need
- An editor
- A browser
- The widget SDK
Ideally this would be
- Eclipse http://www.eclipse.org with JSEclipse plugin http://labs.adobe.com/technologies/jseclipse/
- Firefox 2.x http://www.mozilla.com/firefox/ with Firebug installed http://www.getfirebug.com/;
- The Widget SDK (need link from SVN)
Code Compilation and Validation
- Use The Firefox HTML Tidy plugin to validate markup code. http://users.skynet.be/mgueury/mozilla/
You will probably want to create a maven 2 build for your project to make it deploy as a war. At the moment we want to maintain rapid development and feel that imposing a build onto what is a filesystem development pattern slows down the development. However we may add a build structure that incorporates some of the tools above.
It is vital with any HTML fragment that will co-exist in a borwser window with other HTML fragments that it is well behaved. If we were building a new Facebook, we would provide server infrastructure to ensure that all harmful tags and constructs were striped from the code, but we are not so we are using developer education and code review, which may be automated to ensure that the code conforms. The main requirement is that what ever is expose to the global name space is guarenteed to have a minimal footprint on that space, and to be unique in that space.
The above is slightly better, as now at least the fuctions and global variables probably wont collide with other widgets, but there is still a significant amount of stuff being put into the global space.
Now at least we have one top level variable in global space and all the variables that are needed are protected in the widgets namespace. There is minimal chance of collision with this approach. I am not commenting on the suitability of the methods, just the layout and the impact on other widgets.
Classes, Objects or static namespaces
This is bad because all links in on the page will be styled using the styles from the widget and not from the portal. If anyone else happens to use widget_title, then it will also be styled incorrectly. However from a performance point of view, .widget_title is scoped to the whole document and will slow down css rendering if it is not applicable to the whole document
This is slightly better since now I just need to add the class mywidget to all links within the widget. The widget_title class is still scoped incorrectly.
Now the widget html is encapsulated in a div with class mywidget_container, which enables me to scope my css down to the container. This allows me to write simple class names inside the container but gain control over the css with scoping. It prevents the css leaking into other containers, and optimizes the rendering by reducing the volume of css available at the top level.