March 20th, 2007 by Aaron N.
Another topic we’ve been discussing lately is unit testing. This is especially tricky when you’re writing code that requires a specific context, but even if we had an automated test for all our common libraries – which assume no such context – I think it would help dramatically. Here’s a recent post on Ajaxian about Squish, but, as noted in the post, Selenium seems to be the current favorite for this kind of task…
Squish for Web is a GUI testing tool aiming to be well suited for testing Ajax GUIs (and has special
support for many frameworks such as Backbase, dojo, ICEFaces, qooxdoo, JackBe, etc.)
The Squish for Web edition enables testing HTML-based Web and Web 2.0 (Ajax) applications in different web browsers running on different platforms.
Squish for Web is, unlike many available web testing tools, not restricted to a single web browser or platform. Squish for Web supports running and recording tests for web applications in Microsoft Internet Explorer, Mozilla, Firefox, Apple’s Safari and KDE’s Konqueror on Windows, Linux, Unix and Mac OS X.
Demos
Selenium seems to be the de facto standard these days, but we can always do with new tools to help us test. What do you use?
Posted in Best Practices, CNET JS Standards, Tools | Comments Off
March 20th, 2007 by Aaron N.
Just today I was asked over in the Mootools forums why we don’t create a dependency map like the one in Mootools. My answer there was, basically, that the common code we publish here on clientside is but a small portion of our library. Our javascript spans numerous teams, sites, and applications, and keeping a map like this by hand is probably not practical.
Then today on Ajaxian there’s this post about T.J. VanSlyke’s alterations to Dean Edward’s Base.js to allow him to generate a dependency map of all the classes he writes. This isn’t quite the same as mapping out file-by-file dependencies, but it’s a start. Considering that Mootools is largely based on Base.js, this shouldn’t be too hard to incorporate over there. Read the rest of this entry »
Posted in 3rd Party Libraries, MooTools, Organizing Code, Tools | Comments Off
March 14th, 2007 by Aaron N.
Valerio posted over on the Mootools forums today a list of changes in the upcoming 1.1 version of mootools. We’ve been hard at work on a lot of this stuff and I’m excited to see it come out. After this version, we anticipate working less on the core framework and more on plugins and widgets.
————————————————————————————————————
#Additions
————————————————————————————————————
- CUSTOM EVENTS!
- $each also iterates objects
- added Element::getStyles
- added Element::hasChild
- added Array::include
- added Array::merge
- added $merge, to merge objects
- Dom.js uses XPATH in supporting browsers
- the use of +’px’ in setStyle is not required anymore.
- added XHR::cancel
————————————————————————————————————
#Changes
————————————————————————————————————
- Object.extend is now $extend, still compatible
- Object.native is now $native, still compatible
- Element has been splitted in Element.Events, Element.Form, Element.Dimensions
————————————————————————————————————
#Elements Creation
————————————————————————————————————
- elements creation is easier: new Element accepts second param
- elements creation for elements with name/type is easier, just use second argument.
- setProperty for name/type are is supported anymore.
————————————————————————————————————
#Notable Fixes
————————————————————————————————————
- dom logic is highly optimized and its blazing fast
- better sortables, no more flickering, removed Drag dependency
- Fx.Slide now accepts borders and margins. Positioning is now possible.
- Element::toQueryString in ajax now works as intended with all Form elements, including multiple selects.
- Element::setStyle supports float
- Element::setProperty and Element::getProperty now supports “for”
————————————————————————————————————
#Obvious Things
————————————————————————————————————
- code cleanup and optimization
- bugs and incompatbilities fixed
- mootools is faster, FASTER, FAAASTEEERRR
————————————————————————————————————
#TODO
————————————————————————————————————
- some bugs left
- testing
- css3 selectors (?)
- ???
Posted in 'Industry' News, CNET JS Standards, MooTools, Uncategorized | 1 Comment »
March 13th, 2007 by Aaron N.
I added large close and confirm buttons to the default stickyWinHTML layout. You can make them read whatever you want and you can assign callback functions to them getting clicked. They are optional, and not visible by default. Note the section in the link above about how the onClose event is NOT the same as the onClose event for StickyWin.
That little “x” for closing the StickyWin is pretty small, and on pages like in our CMS, I think an easier to click close button would make it easier to deal with these things, especially if you end up opening them often. If you don’t specify a closeTxt or confirmTxt value, the buttons are not there. The callbacks are not required. Example:
new StickyWin({
content: stickyWinHTML('the caption', 'this is the body', {
width: '400px',
closeTxt: 'close',
confirmTxt: 'okey-dokey',
onClose: function(){alert('closed!')},
onConfirm: function(){alert('confirmed')}
})});
Posted in Examples, Widgets | 15 Comments »
March 8th, 2007 by Aaron N.
Helping out our CMS group today I hacked out a new little widget class called “Confirmer” that handles notifying the user when something they’ve done on the page requires some sort of notice. An auto-save, or the failure to auto-save, or any other sort of message.
It’s designed to be unobtrusive so it doesn’t annoy the user too much if it happens a lot. You can have the prompt inline in the page or floating over it. The message just fades in and then back out. It comes with default styles that can easily be overridden, the message displayed can be changed every time you call it, and its easy to position it relative to an element or at the edge of the screen.
Quick example:
new Confirmer().prompt(); //watch the upper right of your screen
More examples and details in the wikitorial.
Posted in Event Scripting, Examples, Widgets | Comments Off
March 8th, 2007 by Aaron N.
Part of writing clean code that doesn’t cause you grief in esoteric browsers is doing the best you can to ensure that your code is completely syntactically valid. My pal Valerio (principle author of Mootools) pointed out how to turn on strict warnings, which I couldn’t get to show up in Firebug, even though I enabled them there.
The problem turned out to be the excellent Web Developer Toolbar which, if you haven’t installed, you should.
The issue is that the default setting in Disable > Javascript > Strict Warnings is to suppress these errors, so even if you enable them in Firebug, you won’t see them. You have to enable them in both places. Read the rest of this entry »
Posted in Best Practices, Browser Plugins, CNET JS Standards, Reference | 3 Comments »
March 1st, 2007 by Aaron N.
Over at Ajaxian today they have a post on miniajax.com which describes itself as “a showroom of nice looking simple downloadable DHTML and Ajax scripts”.
I’m not sure if they authored these scripts or if they just collected them all into slick looking examples. Some of the items link to other sites, but some they seem to host.
Some of these things I think would do well to write as plugins for the Mootools library but if Valerio (the gatekeeper for Mootools) doesn’t want it I think some of them would do well to be added to the CNET Library.
This goes hand-in-hand with the patterns project that we’re trying to kick off here. I think this page could really help inform that work…
Posted in 3rd Party Libraries, Examples, Visual Effects, Widgets | 2 Comments »
