Friday, September 30th, 2005
Category: Editorial
We have setup Planet Ajaxian as a place to aggregate various Ajax and Web 2.0 content.
If there are Ajax sources that you think should be added to the planet let us know.
Ideally, the source will either be 100% Ajax, or have an Ajax category, as we don’t want to have content about someone’s cat or anything like that :)
We want to keep the balance on how much content to put on the planet, and would like to keep the list kinda small so we don’t have 300 entries a day flying by!
Category: Articles
Amit Klein has written up ideas on security issues to watch out for with XHR in his paper, Exploiting the XmlHttpRequest object in IE - Referrer spoofing, and a lot more…
Introduction
XmlHttpRequest is a Javascript object that allows a client side Javascript code to send almost raw HTTP requests to the origin host and to access the response’s body in raw form. As such, XmlHttpRequest is a core component of AJAX.
It seems that the same origin security policy ensures that the power of XmlHttpRequest is only used in a secure manner (after all, if the Javascript code can only access the server it originated from, then what harm can be done, except for XSS conditions), but this is not so. In fact, about 2.5 years ago I noticed a problem in XmlHttpRequest’s implementation in IE - IE doesn’t validate some critical fields that are provided by the user [1]. Back at that time, the attack vector was through an XSS condition, but the basic flaw (and other, related flaws) renders itself nicely to other conditions, which we’ll see below.
The techniques discussed below allows the attacker (given the right conditions) to perform:
- Referer spoofing (for leeching and for complete client-side
MITM attack)
- HTTP Request Smuggling, HTTP Response Splitting and
Web cache poisoning
- Accessing content / web-scanning
Category: Toolkit
The Japano Web Application Toolkit is a marriage of JSP taglibs and a core Javascript library.
This means that you end up with code like below that sucks in the javascript, and uses the jpn taglibraries to dynamically load a partial page:
<script language=\"javascript\" src=\"${pageContext.request.contextPath}/japano.js\"></script>
<jpn:javascript>
function loadIndex() {
// load the part with the id \"content\" from the index.jsp and feed it to to an
// inline function
japano.getHTML( japano.convertToURL(\"index.jsp\"), function(result)
{
var e=document.getElementById(\"dynIndex\");
// replace the current div with the newly loaded div which has \"content\" as id
e.parentNode.replaceChild(result,e);
// restore the former id.
result.setAttribute(\"id\", \"dynIndex\");
} , { \".part\" : \"content\"});
}
</jpn:javascript>
<jpn:button fn=\"loadIndex\">Load Index Content</jpn:button>
Japano home page
Thursday, September 29th, 2005
Category: Dojo, Showcase
A bunch of people have mentioned the announcement by Jot of Jotspot Live, which is a “Live, group note-taking” service built on Dojo.
We checked out the service, and it was a pleasure to fool around editing things. A pretty seemless experience all around, and you can check out some screen shots below.
We managed to chat with Abe Fettig, the developer behind Jotspot Live, on the launch:
What made you think of Jotspot Live?
The idea for JotSpot Live came at the end of March. I’d just gone to PyCon and seen Donovan Preston’s talk on LivePage, which lets you do two way communication between a web server and browsers. That got me thinking about what a live Wiki would look like.
At the same time, I was feeling annoyed by the way Wikis become less useful as the time between edits shrinks. When there’s a bunch of people interested in editing the same page at roughly the same time, you’re going to have conflicts. At JotSpot, our Wiki gives the editor a lock on the page, which prevents people from clobbering each other’s changes.
But before every company meeting there’s be a lock war as all of us tried to update our bits on the meeting agenda page. What bugged me about that is that I knew the changes we were making were in different parts of the page.
The idea from JotSpot Live came from those two lines of thought: fine grained editing and locking combined with live updates. I had a chance to try implementing the idea at our hackathon a little while later, and
(surprisingly) it seemed to work! As you can see from the hackathon blog post,
the core features of Live have been there from day one.
What are the target users and use cases?
I think JotSpot Live is useful any time you have more than one person writing about the same thing. That means meetings, classrooms, conferences. It’s also especially nice to use when you’re geographically separated from the other people you’re meeting with: you can all be looking at (and contributing to) the exact same set of notes, even though you’re not in the same room. And you don’t have to pick one person to be the official note-taker.
In many ways, though, I don’t know what the use cases for Live are going to be. We wanted to get it out there to see what people did with it. For example, since the launch on Tuesday I’ve been exchanging emails with a college professor who’s using Live to assist his English class students with their writing. That’s a use case I hadn’t thought of (and it brings with it its own set of feature requests, like Word import), but I’m thrilled to see it.
In your opinion, what are the “cool” features?
Did I mention it’s Live? :-) That’s definitely the coolest feature: even the simple fact that pages in JotSpot Live have presence is cool. It’s nice to see who’s there on the page with you at that moment. I also think our keyboard shortcuts are cool: you can use the arrow keys to move around the page, enter to edit something, ctrl-enter to save, esc to cancel and edit, and the delete and insert keys to delete and insert.
Having the obvious keyboard shortcuts work makes it feel more like a real app and keeps you in your flow. Keyboard shortcuts are something more web apps should think about.
I’m also happy with our support for drag and drop: You can grab any block-level element and move it around on the page. If you drag a paragraph into a list, it’s transformed into a list item. And after you’re done dragging all the other users see an animation of the thing you moved moving on their screens, so it’s clear to them what happened.
How do you handle the “live” part? Polling?
We’re using a (very slightly modified) version of LivePage, which Donovan Preston wrote as part of Nevow, a Python library for building web applications using the Twisted networking framework (which I just wrote a book on: Twisted Network Programming Essentials). LivePage doesn’t use polling. Instead, it uses a clever technique where each browser keeps an open XMLHTTP request to the server at all times, opening a new connection each time the old one closes. That way every client viewing the page is constantly waiting for a response from the server. When the server wants to send a message to a client, it uses the currently open request. So there’s no waiting.
What were the challenges for building the app?
The biggest challenge was making it work right in all the browsers. We support Mozilla/Firefox, IE, and Safari, and it definitely feels like we’re starting to push the limits of what they were designed to do. I saw some truly weird browser bugs while developing Live. IE in particular seems to have trouble keeping track of the state of the page when you’re making lots of changes to the DOM. Sometimes it freaks out and starts hiding elements, swapping the position of elements, or inserting seemingly random text into the page. Firefox is much more consistent, but has some crasher bugs that we have to be careful to avoid. Safari is like the well-behaved younger child: it generally does what it’s told without acting up, but there’s some things it just doesn’t know how to do yet.
Thanks, these were good questions and it was fun to answer them!
Screen Shots
Category: Showcase
Pluck is a new web based RSS reader. They are several forms (Firefox, IE, and web) but the simple web based version is what is interesting to us.
It follows in the “application just via your browser” niche, like Yahoo! Mail.
It was pretty nice to use, but it didn’t like my OPML file. Probably too big so it freaked out? :)
Category: Examples
This should be filed under the quirky category :)
Julien Lamarre has demonstrated doing Ajax-style callbacks not using XHR. Nor iframes. Nor Java. Nor Flash.
He implemented it with images and CSS.
Ajax using an image
- The client to server connection works by sending a request to the server using a dynamically created image with some parameters added to its “.src” property.
The server’s response is sent in a cookie at the same time the generated image is returned to the client. Or, when cookies are disabled, by using the image’s width and height to send, two by two, the characters forming the response!
- There are some limitations and performance issues related to this technique, especially when cookies are disabled on the client.
- A lot of improvements could be done. In the cookie version for example, an iteration method that would split the server’s response and send it chunk by chunk would be a good idea to deal with a cookie’s size limit.
- The associated PHP file: image.php
Ajax using a stylesheet
- This technique will only work if your browser supports [an element].currentStyle() or window.getComputedStyle(). This means it won’t work with old browsers.
- The client to server connection works by making a stylesheet’s “.href” property point to the PHP file, followed by the request’s parameters.
The server’s response is done by generating a stylesheet that includes the response inside the “background-image” property of an hidden div.
- This technique’s main limitation is the number of characters that can be used for a “background-image” property’s value. An iteration method that would split the server’s response and send it chunk by chunk would be a good idea to deal with this.
There is also the fact that only recent browsers can be targeted.
- The associated PHP file: stylesheet.php
Wednesday, September 28th, 2005
Category: Utility
Morfik is announcing a new Ajax development environment.
Morfik IDE differs from other tools due to its JavaScript Synthesis Technology (’JST’) that allows developers to use a visual design environment and a high-level language of their choice to create applications comprised purely of HTML and JavaScript.
So, this sounds like they take your code written in YourLanguageOfChoice and convert it to JavaScript? I can’t seem to see what choices you have for the language…
JST is a true compilation process which avoids boilerplates or code snippet libraries.The source code is put through a parser which includes a tokenizer and syntax analyzer. The parser output is then passed to a semantic map builder which creates a detailed semantic map that conveys the entire ‘meaning’ of the application - a highly effective technique in widespread use by CAD systems. Finally a synthesizer uses this map to create JavaScript code that is semantically identical to the original source and conveys the same ‘meaning’. This output is neither an executable in machine-code, nor a one to one translation of source code, nor a collection of predefined code snippets, but rather it is an accurate semantic equivalent of the programmer’s source code!
Screenshots
It looks MDA-ish, and the question will be, will users want to use a new tool like this, or will they actually want to get in with JavaScript (as if anything goes wrong in the JavaScript code you have to get in there anyway?)
Thoughts?
Category: Examples
The Stickman posted a solution that lets you have one displayed <input type=”file” …>> that allows you to select multiple files (one by one), and then send them all up to the server.
The implementation creates multiple file upload inputs, and keeps all but one hidden.
Read about the solution
Download the code
Tuesday, September 27th, 2005
Category: Showcase
An asian site, with a Tonga address, has created an interesting Ajax Photo Viewer named Piccy.
The viewer has a cool slider that allows you to dynamically slide the size of the photos in the album, and then of the image that you actually click on.
It also seems to have all of the tagging love a la Flickr.
The app uses Scriptaculous and Prototype, and you can see the usual effects (fading in and out)… maybe a bit TOO much at times?
Category: Editorial, Articles
Dan Grossman, the VC that brought us Top 10 Ajax Apps, has now told us what is wrong with Ajax.
He has brought out the old chestnuts:
First Problem: User Interface Issues
- The back, stop, and refresh buttons don’t always work.
- Since Ajax applications generate pages dynamically, there generally aren’t static links available for bookmarking or sharing with others.
- Pages don’t always print well.
- Applications don’t run offline.
- Clicks and actions generally don’t get included into a browser’s history table.
We need to be aware of issues like this, but we have fixes for many of these already, and more are coming.
Second Problem: Ajax requiring JavaScript and ActiveX on IE
Sure, sure. Is that such a huge issue these days? And IE 7 will have native support for XHR at least.
If we keep coming up with quality Ajax applications, then that will be the reason to have JavaScript turned on!
Third Problem: perceived application performance
It is easy to make something slow, or seem slow. However, you only need to play with Yahoo! Mail beta to see how a fully functional app runs like a charm. So, we can do it, and it will only get better for us!
There are definitely issues, and there are MANY things that we all wish we had. But, none of these should scare us.
It is interesting to read Desktop Ajax as Desktop.com Returned where Paul says:
What I really want from Ajax apps is for them to do stuff that it’s too hard to do with binary apps. I want them to be sensibly integrated with online resources; I want them to support realtime collaboration. I want them to do different stuff from Word/Excel/Powerpoint, not just do the same thing with a different engine under the hood.
We need to find our way with Ajax applications. Let’s not just port over to the web way, with a poorer version due to the limitations. Rather we need to embrace the differences and do as Paul says. Do things that suit the web better.
Category: Utility
Joe Walker now has a new favourite JavaScript editor in JSEclipse.
JSEclipse is obviously an Eclipse plugin, that has features such as:
- Code completion for JavaScript function and classes.
- Code completion for JavaDoc.
- Function and class names are displayed in the Outline panel for the currently open file.
- Open declaration
- Error reporting
- Warning reporting
- Code wrap
What surprised Joe, was that some of the completions seemed to be not possible to him. They “appear to work based on usage - it remembers how an object is used and completes based on that.”
This proves that completion can be possible in dynamic languages.
Joe was also impressed with how it grokked JavaScript taken to the extreme.
Read Joe’s mini review
Monday, September 26th, 2005
Category: Showcase
Tom Snyder of ForwardCenter, Inc. has released inetWord a fully functional HTML editor written using Ajax technology.
Info
- The editor UI never reloads, even during document save, autosave, open, spell check, etc. This is great because coding a whole application in JavaScript takes a lot of code.
- The formatting dropdowns and dialog boxes are very responsive.
- The editor uses full CSS and can perform any edits that a desktop editor can (e.g. FrontPage). No widget compromises. Tech note: we’ve overcome the limitations of execCommand() which has up ’til now limited browser-based editors.
- The home page is the editor. Anyone can run it without logging in. Free accounts are available if you want to save or publish you pages. A simpler, traditional (no script) home page is here.
The quickest way to understand inetWord is through our brief demo videos. Here’s a chart detailing the editor capabilities. Here’s a gallery of templates (built using inetWord) that come with inetWord.
inetWord is built with iframes and simple onload= events to process server responses. The client side is pure JavaScript and the server side is PHP. InetWord currently requires IE 6.0. A Firefox version is in the works.
Category: Accessibility
Mike Davidson got together with a group of developers to work on a method to insert rich typography into web pages without sacrificing accessibility, search engine friendliness, or markup semantics.
The method turned into sIFR (or Scalable Inman Flash Replacement):
How it works
sIFR is meant to replace short passages of plain browser text with text rendered in your typeface of choice, regardless of whether or not your users have that font installed on their systems. It accomplishes this by using a combination of javascript, CSS, and Flash. Here is the entire process:
- A normal (X)HTML page is loaded into the browser.
- A javascript function is run which first checks that Flash is installed and then looks for whatever tags, ids, or classes you designate.
- If Flash isn’t installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you’ve designated as something you’d like “sIFRed”.
- Once measured, the script creates Flash movies of the same dimensions and overlays them on top of the original elements, pumping the original browser text in as a Flash variable.
- Actionscript inside of each Flash file then draws that text in your chosen typeface at a 6 point size and scales it up until it fits snugly inside the Flash movie.
This all happens in a split-second, so all of the checking, replacing, and scaling is not visible to the user. It is not uncommon
to notice a very short delay as the Flash loads, but to the user, none of the internals of this process are exposed.
Resources
Category: Editorial
As I was watching “24 hour party people” on DVD, I heard the main character talk about the ebbs and flows of the music business. He is talking about the scene in Manchester at the end of the 70’s, and into the eighties. Moving from Joy Division to Happy Mondays and New Order.
I think that we are in a new chapter for the web, and as is often the case, the wheel of time is repeating history for us.
There are a few dimensions to the current war though. They are on the client side (DHTML Ajax vs. simple HTML vs. Flash/PDF vs. XAML vs. XUL) and on the server side (Rails vs. Java vs. PHP vs. .NET).
Let’s start at the beginning.
Perl: Birth of CGI
Do you remember how the web changed as it moved from static HTML connected content to dynamic websites? That came about due to CGI, and how our nice web server would now fork off our programs to generate the HTML.
I remember my first CGI programs were written in C, and Scheme. I quickly moved on though, and found the beauty, and craziness of Perl.
I spent quite some time with Perl, trying to get by without writing too much NSAPI and ISAPI code (oops, I guess that core dump hurts the entire server?).
I really enjoyed the community at that time. #perl was interesting (some of the time), and CPAN became the holy grail. As soon as you thought you needed something, someone had kindly put that functionality up into CPAN. I even have some of my own modules hanging out there, and helped with others.
Over a short time period, we had developed some fairly rich web modules. We didn’t have to work with $ENV{’SOME_CGI_ENVIRONMENT’}, or STDIN or the like. Our framework abstracted all of that for us, and gave us a simple model. We lauched at the folks who generated html via methods such as b("whee") and we stuck close to HTML itself, allowing our design teams to simply open the html files and see what their stuff looked like. We even had the notion of components, and special tags that you could create. <$mytag name=”…” /> was nice because the name of the tag was the key for the framework to dynamically discover that functionality. No config files, or interfaces, in the strict sense. The coupling was based on a name.
In retrospect, life was pretty simple for web development, a lot simpler than some of the frameworks we have today!
But, we moved from Perl. CGI was not the nicest for our high load servers. It was crazy to think that we would fork a process for every little request that came in, and that a Perl interpreter would start up, load the program, do the work and then die off.
We naturally moved to solutions such as mod_perl, and that helped. It was so new though that it was buggy and we had a lot of problems. Some of the problems had nothing to do with mod_perl itself, but due to laziness and side-effects.
When you work in an environment like CGI you can be a very bad man indeed. If you don’t close something correctly, or don’t play totally nice with resources, baaaah who cares? The server is going to kill me in 2 seconds anyway, so I will get my job done and have him kill me. In mod_perl world though, these programs start to live longer, and they get fat and oily.
Java: No more stinking processes!
Remember the beginning of Java (Oak!). We were building applets, and feeling the pain very early on.
Servlets were the big thing though. We ported our Perl based framework over, and were able to see significant performance improvements at the time. Some of the team loved the change, others hated the verboseness and static typing.
The nice threading model that Java gave us was huge though, even with the poor JVMs back then (Microsofts was by far the best remember!).
This is when we moved from the world of Perl to having Java start to take over. That isn’t to say that there wasn’t competition. In the waters we saw the lurkers of ColdFusion, ASP, and the beginning of the PHP revolution. Java came up with JSP to compete with these tag based approaches, but it was the advent of the rich MVC style frameworks that really spurred everyone on.
In my opinion Java is still in the hot-seat, especially in the corporate world.
Preparing for the server war
The troops are being gathered. Strategies are being worked out. We are currently getting ready for a new battle on the server side.
What’s happening?
- Ruby on Rails: Whatever you think about Rails, it has lit a fire under the server side web development community. Many have jumped on the bandwagon, claiming real productivity improvements. Some of the PHP converts enjoy a richer language, which is still nice and dynamic, with a framework that enforces clean MVC techniques. Some of the Java community are frankly a little bored of Java, and enjoy the new challenge. They also love the freedom of the language, and the fact that they now have just ONE stack to worry about. Will the Rails buzz keep growing? Will it be the Perl of Web 2.0?
- Java: Java isn’t going down without a fight. Some argue that the problem with web development in Java is that it has been too complicated and heavy for much usage. I have personally called for the need of a common stack for Java, and people have stepped up to the plate. On one side we have companies that will certify a set of technologies (JavaServer Faces + Spring + Hibernate). Then we get frameworks taking on simplicity themselves (WebWork now embedding Spring). Finally we have initiatives like JBoss Seam, which is trying to combine the component models of JavaServer Faces and the backend. Seam aims to give you the power of the Java tier, but also giving you a simple productive environment. So, Java frameworks are rising to the challenge of Rails, and we will soon see how much of the success of Rails is Ruby, and how much can be duplicated in other platforms.
- PHP: We can’t discount PHP. A lot of “serious engineers” (read: anyone who isn’t a PHP developer thinks they are serious) poo poo the PHP world. Yet, by all accounts, there is a LOT of PHP development going on out there. PHP has the advantage of being something written JUST for the web. Take a look at how Wordpress came along (PHP based blogging software) and in no time at all there were thousands and thousands of plugins that you could simply drop into your Wordpress system. Literally, you drop in a file and you are done. There are numerous PHP frameworks that are aiming to mimic, and compete with Rails, so we can’t forget about these guys. The question with the PHP community is: will it grow more into the enterprise, or will it be for script-kiddies.
NOTE: Some people have concluded that this is anti-PHP, or making fun of PHP. This is NOT the case. It is making fun of the people that make fun of PHP :) I know that my british sarcasm is hard to see in print. We have worked on PHP projects, and like how pragmatic the platform is. PHP was made for the web, and it shows.
- .NET: Never discount Microsoft. ASP.NET keeps getting more productive, and it is hard to compete with their end to end story, which includes fantastic tooling in their latest Visual Studio. And, we get Avalon and XAML along for the ride, as well as the futures of C# 3.0 which takes a lot of ideas from the dynamic languages and puts them into a static structure (such as: var foo = new Bar(); and the relational/xml integration)
It is going to be an interesting couple of years, as all of these platforms mature, and take eachother on, trying to get mindshare!
Client Side: JavaScript is cool again
But what about Ajax? The battle for the client side is going to be just as hot as on the server. And they will even intertwine with eachother.
Firstly we have the big debate of how far Ajax is going to go. Is it a one hit wonder? or will it become a standard part of our toolbox and even just be called dhtml again?
As an Ajaxian, I obviously have my thoughts on this matter. But there is a lot of competition inside and outside of Ajax:
- Flash/PDF: Adobe/Macromedia are a definitely force to be reckoned with. Flash is almost ubiquitous, and PDF is used everywhere. Now the companies are combined, what do they have in store for us?
- Avalon/WPF/E/XAML: Microsoft announced WPF/E, which is a subset of XAML that will be ported on various platforms and available in many browsers. This means that you can build your rich application in the .NET set of tools, and have it run in Safari on Mac OSX. Impressive. When are we actually going to see this in a form that we can deploy to the real world?
- HTML: How much do we want to work in the open (ish) world of HTML. A large group of developers do not want to jump into any monopoly, and will therefore want to stick to a more open environment. But, another set will just want to use the best tool to add business value. What will the split be?
JavaScript will play a big role in this war. JavaScript 2.0 offers big improvements, that many people will cheer for. Also, the same people who poo-poo’d JavaScript in the past have come to realise that it really is a great language. It may not be what they are used too (it uses prototype-based OO vs. class-based OO), but it is powerful and robust. There are some features missing, and a big question around libraries. JSAN and others are trying to build a CPAN for JavaScript. We also worry about the black box of the JavaScript VM in the browsers, and cross-browser bugs are truly real painful. Fortunately, frameworks like Dojo and Prototype are trying to help us out on that front.
We are also seeing that we need to take JavaScript from the former:
“That is just crappy code that the web dood View-Source’s and pastes into the web pages”
to the future:
“JavaScript also needs to be engineered, and is a first class citizen”
Thus we finally see more unit testing of JavaScript code, and professional ways of creating modules and namespaces for our code. We also see great advantages with features like E4X where XML becomes a native type.
JavaScripts increased popularity, thanks to Ajax (and Flash/ActionScript) has also drawn it into the server side. Mozilla Rhino gives you a quality Java-based approach, so why not use a cool dynamic scripting language for certain tasks on the server side? You don’t have to use JavaScript for everything, but it has its place, and that place is growing.
The Battles Join
This is where the battles are joining. We have JavaScript bleeding across the layers, and we have the need for server-side frameworks to support the new Web. It isn’t enough to generate simple HTML and be done with it.
Today’s frameworks need to be able to help us build Ajaxian components, and help us write this applications quickly and cleanly.
There are various directions that frameworks are going in here.
- JavaScript Code Gen: Why not give you a simple macro that splits out the ugly JavaScript that you would have to write?
- JavaScript Framework Code Gen: Spitting out low-level JavaScript is too much work. Many frameworks are writing on top of a higher level JavaScript framework like Dojo or Prototype. Now the code-gen is less, and you get the benefits of the rich functionality, browser compatibility, and visual effects available from these frameworks.
- Tools and Widgets: Should developers even care if a piece of their page is Ajax or not? Some frameworks give you drag and drop editors that let you setup widgets or components. Some happen to be ajaxian. Some are not. Who cares?
- Markup based: A lot of frameworks are giving us markup based solutions. That is one of the strengths of Microsoft Atlas, not the fact that they added support for $() etc. Are we going to want to build using markup or via programatic APIs?
Conclusion
It is hard to predict the winners of the new battles, and the losers will not die off totally, but it is an exciting time to be watching web development. The dynamic languages of Ruby, JavaScript, and PHP are making a big run, and people are realising that they aren’t just cheesy scripting languages that can’t be used. It’s time to take them serious.
We are going to start really working out what makes sense for usability on the web with rich interfaces. And, at the same time we will get simpler and simpler backend tools to make the generation of rich web experiences easier and easier.
I am looking forward to seeing this battle!
ps. I know that I haven’t listed every possible technology, and I apologise for not mentioning your technology. This is due to not being able to list everything that is possible.
Sunday, September 25th, 2005
Category: Toolkit, Prototype
Both Prototype and Script.aculo.us have announced upgrades.
Prototype
Firstly, there is a new Prototype 1.4 available for download that:
features JSON support, a nice new Range object and some other goodies.
Including being able to do things like
Generate sorta-kinda-UUIDs in JavaScript with Prototype 1.4.0_pre6
function UUID() {
return [4, 2, 2, 2, 6].map(function(length) {
return $R(0, length, true).map(function() {
return (Math.random() * 256).toString(16);
}).join('');
}).join('-');
}
/* UUID()
* => \"eea637ad-e840-dc78-8199-d1c176f3a170\" */
Script.aculo.us
Thomas Fuchs has announced the first release candidate of the upcoming version 1.5 of script.aculo.us.
What’s New
Compared to the previous V1.0, it has tons of new stuff for your web apps to look and feel better:
- In-place Editor control
- Slider control
- Completely new effects engine with queuing, delaying (read: timelines) and text effects
- DOM Builder
- Drag and drop and sortables with ghosting
- Sortables can drag and drop between empty lists
- Unit testing framework
- script.aculo.us autoloader (script.aculo.us components get loaded automatically, only one JavaScript file has to be included)
- There are also tons of bug fixes and little tweaks to make it all the more enjoyable.
A big thank you to all contributors and bug reporters!
—
Next Page »
