Sunday, August 5, 2007

Eval’ing with IE’s window.execScript

Plaxo’s Joseph Smarr has been playing with on-demand javascript, i.e. downloading extra JS code after the page has already loaded. When you grab the code via a remote call and eval() it, it doesn’t get into global scope. So here’s how he dealt with it.

Here’s a simplified version of the situation we faced:

function loadMyFuncModule() {
// imagine this was loaded via XHR/etc
var code = 'function myFunc() { alert(\"myFunc\"); }';
return eval(code); // doesn’t work in FF or IE
}

function runApp() {
loadMyFuncModule(); // load extra code “on demand”
myFunc(); // execute newly loaded code
}

The thing to note above is that just calling eval() doesn’t stick the code in global scope in either browser. Dojo’s loader code solves this in Firefox by creating a dj_global variable that points to the global scope and then calling eval on dj_global if possible:

function loadMyFuncModule() {
// imagine this was loaded via XHR/etc
var code = 'function myFunc() { alert(\"myFunc\"); }';
var dj_global = this; // global scope object
return dj_global.eval ? dj_global.eval(code) : eval(code);
}

This works in Firefox but not in IE (eval is not an object method in IE). So what to do? The answer turns out to be that you can use a proprietary IE method window.execScript to eval code in the global scope (thanks to Ryan “Roger” Moore on our team for figuring this out). The only thing to note about execScript is that it does NOT return any value (unlike eval). However when we’re just loading code on-demand, we aren’t returning anything so this doesn’t matter.

The final working code looks like this:

function loadMyFuncModule() {
var dj_global = this; // global scope reference
if (window.execScript) {

window.execScript(code); // eval in global scope for IE
return null; // execScript doesn’t return anything
}
return dj_global.eval ? dj_global.eval(code) : eval(code);
}

function runApp() {
loadMyFuncModule(); // load extra code “on demand”
myFunc(); // execute newly loaded code
}

And once again all is well in the world.

How to write a Google Gadget

I’ve written some notes on the Google Gadget API and how to write a gadget, targeted at developers who already know Ajax.

What’s a Gadget?

  • The gadget is an XML file sitting on your server. In my case, http://ajaxify.com/run/widgets/google/diggroundup.xml. It will get cached, so effectively it must be a static file.
  • The user adds your gadget to their igoogle portal, or codes it into their own website, by specifying this URL (it may be done indirectly - via the gadget registry. You’ll appear in the registry if you’ve submitted your gadget to igoogle.)
  • The gadget is rendered as an iframe, so you have all the usual security constraints which stop you borking the portal and other gadgets. This also means you can’t communicate with other Gadgets other than via than remote calls to a common third-party server (or has anyone tried hooking them together using the iframe-fragment identifier hack? ).

It’s based on a Digg Roundup tool, where the gadget show Digg stories according to user preferences such as topic and whether to go for popular or upcoming stories.


source: ajaxian.com

Current Concerns with Ajax

Our fellow Ajaxian Michael Mahemoff, has written about his current concerns with Ajax.

His main concerns are:

  • Accessibility
  • Documentation: it is getting better for Prototype, Dojo, and the rest
  • Lack of good cross domain option: Are you jealous that Yahoo! can put in a crossdomain.xml in for Pipes and Flash API users can do what they want with it?
  • Cross-browser programming is still painful
  • Comet (HTTP Streaming) is becoming really important, but is still out of reach for the typical Ajax programmer. Too resource-intensive, too many issues to overcome, especially in the server.

Do you agree with these? Do you have other concerns?

Five Ajax Anti-patterns

I have liked Jack Herrington since I read his book Code Generation in Action which is one of the very few pragmatic treatments of the subject (no dumb MDA there!)

Jack has recently written up his thoughts on five Ajax anti-patterns which are:

Polling on a timer when you don't need to

Beware window.setInterval() code. Jack rips apart a simple example, and ends up with a nice usage for autocomplete.

Not inspecting the return results in the callback

Check for if (req.readyState == 4 && req.status == 200 ) {. That being said, I would argue that for almost all cases, you shouldn't be writing directly to XHR. Use a framework. There are a couple out there these days.

Passing complex XML when HTML would be better

"I don't want to send back HTML as I want to be pure". There is a place for talking XML, but often life is easier if you just speak HTML and innerHTML all day.

Passing XML when you should pass JavaScript code

The benefits are clear. In this example, there was a 52% savings in the size of the data blob downloaded to the client by going with the JavaScript language. There's a performance increase, as well. It was 9% faster to read the JavaScript version. While 9% might not seem like a lot, just remember that this was a fairly rudimentary example. Larger blocks of data or more complex structures will require more XML parsing code, while the JavaScript code will remain unchanged.

Doing too much on the server

There is always a balancing act on the client vs. server question. Often more of an art than a science.

What do you think? What are anti-patterns that you see out there?

Monthly Ajaxian Roundup for June, 2007: Airing out the Gears

High Level / Big News

June has been a busy month, and the focus has been around the release of Google Gears, and the Apple iPhone. Both have shaken up the market showing the the future for Ajax is bright and expanding. It is reaching to the desktop, and the phone.

Offline: Gears and AIR

Shortly after Gears was released we saw a flurry of activity that consisted of apps being ported to work offline and libraries being extended to support offline use:

Adobe renamed Apollo to AIR and continues to stay in the news:

Mobile / iPhone

The hype around the iPhone is almost unprecedented. We have tried to keep from joining in, but there has been a lot of interesting work done around Ajax support, and the iPhone is pushing the bounds on Mobile Ajax, just by getting users online. The users will demand more, and vendors will have to step up. We will then have to deliver the applications that they deserve. In the US there isn't the luxury of a top notch network, so we need to deliver it in a smart way too.

Browsers and Standards

With Safari for Windows being announced there has been a lot of talk around browsers. We also got some good news with significant IE memory leaks being fixed.

Ajax Libraries

General JavaScript

GWT

Moo

The FancyUpload with MooTools component is yet another attempt to help with browser based uploads.

Ext

Ext is growing from strength to strength. The team announced Ext 1.1 Beta + Feed Reader 3 Demo, thoughts on 2.0 alpha, a new Ext Accordion Control, and IDE support via Spket IDE: Ext Support. I think July will be an even bigger month.

Prototype

jQuery

Showcases

Some high profile sites and apps have gotten an upgrade such as Apple, CNN, and Google Docs and Spreadsheets Updated.

We also saw useful tools such as an Entity Lookup that helps.

source : ajaxian.com

Bay Partners Announces Facebook AppFactory Seed Program

Salil Deshpande has announced a bold move with the Facebook AppFactory. Bay Partners is announcing The AppFactory, a seed program to fund Facebook application developers via a fast-track process.

This program shows that Bay Partners believes that Facebook, in essence, has become the Social Operating System. And historically the creation of an operating system, or platform, has always led to the creation of an applications market atop that platform. "We think that the Facebook platform is broad enough, technically sound, appealing to businesses, and such a culture-fit for today’s internet ecosystem that it will become a significant and meaningful social operating system platform, if not the dominant one."

We asked Salil, Partner at Bay Partners, a few questions on the news:

What are you investing?

We will award between $25,000 - $250,000 to between 10 and 50 entrepreneurs with a flexible, fast-track process. Because early investments of this size are really bets on people and concepts, Bay Partners looks at the AppFactory as a fantastic relationship starter with tomorrow’s innovators. Because the investments are small, when compared to traditional venture investments, and because the amount of due-diligence that be done on kernels of ideas is often also small, Bay expects entrepreneurs to invest no more than a few hours into the process, and expects to make go no-go decisions in days rather than weeks.

What does this mean for Ajax developers?

With announcements such as this, and Google Gadget Ventures, firms are putting money where their mouth is. We are seeing the birth of web platforms, and these platforms become distribution mechanisms for entrepreneurs. The technical bar is lowered, as it is easy to create applications on top of Facebook, Google Gadgets, and the other platforms out there.

Currently we see simple, almost trivial apps. As time goes on those apps will become more and more sophisticated, and will be a blend of on-platform and off-platform experiences, and will likely involve a lot of Ajax.

What types of applications do you foresee coming from this platform?

We definitely see the open Facebook platform resulting in real, valuable applications. We believe that the Facebook apps of the future will be deep and sophisticated and will strike the right balance between adding value to the Facebook fabric, and having value independent of Facebook. For example, a shipping app that lets Facebook friends transparently use a service such as LicketyShip to physically lend and borrow books listed as favorites from each other, can monetize by charging for the shipping. A stock picking app that lets friends view each others’ stock portfolios could monetize at the point where friends want their own portfolio to reflect a friend’s picks.

And can people really make money from Facebook applications?

Yes! Incorrect conclusions are being drawn from the unmonetizability of some apps that have spread fast on Facebook to date. Some apps are like jokes that get forwarded around by email – and will always be unmonetizable. But meaningful apps will be monetizable just as meaningful web 2.0 websites are monetizable. We are interested in backing entrepreneurs that will be imaginative about what types of applications can be built on Facebook’s Social OS.

Facebook’s user interface is critiqued as being sterile - not very rich , flexible, customizable, or personal. Will this change things?

First off, the Facebook apps we are looking to fund are not necessarily those that focus only on jazzing up the user experience. Having said that, yes, we definitely think that the open API will allow a whole new level and set of rich experiences to be available on Facebook. Now that Facebook has put itself in the platform business, the application developer community is bound to create rich user experiences, whether they are enhancements to Facebook’s current user experience, or alternative user experiences.

What will the other social networks’ APIs look like?

Here’s some bold speculation. By the time other social networks open up their platforms, Facebook may have a sizeable lead in developer mindshare, and in the number of applications on their platform. The other social networks may struggle if they introduce APIs that are not compatible with Facebook’s. We think that the other networks should consider making their API compatible, if not identical, to the FaceBook API. This will allow one-click deploy of apps written for the FaceBook platform, onto the other platforms, thus mitigating Facebook’s lead. And we think they will seriously consider this.

This once again shows what a great time it is for Ajax developers. Everyone wants us!

Best uses of Ajax in Wordpress Plugins

Pete Cashmore has posted about the 30+ AJAX-Powered WordPress Plugins that he things are good.

He has split-up the plugins into two categories, for the blogger, and for the reader which includes:

Blogger

  • AjaxWP - Adds AJAX to all aspects of your WordPress site speeding up the load times.
  • Alexa Rank - Display your Alexa rank with pride.
  • Ajax Comment Preview - Allows readers to preview their comment before submitting.
  • asTunes - Retrieves data from your Audioscrobbler/last.fm profile and posts it as a list on your blog.
  • Codebox - Side scrolling box for displaying code snippets.

Reader

  • AJAX Comments 2.0 - Auto updates the comments page with no full reload, much smoother commenting than the older full reload system.
  • AJAX Google Video Search - Search Google Video without having to leave your favorite blog.
  • AJAX Shoutbox - Realtime conversation with sound to alert of new messages.
  • Cool Weather - Allows visitors to see the weather forecast for any area they define.
  • Currency Converter - Adds a real time currency converter to the page with data pulled from Yahoo Finance.
  • Google AJAX Search - Allows you to set search for just the contents of your site and the web, or another option allows for search of a second site such as your Flickr account.
source : ajaxian.com

Ajax Web Developer: $240k per year… with only one catch

We recently got pinged about a job request that we just had to post about :)

If you like coding in Ajax, and know how to shoot a gun, this could be for you.

* Title: Web Developer
* Salary: $200K plus DOE
* Taxes: No Federal taxes taken out for the contractors that accept a 12 month. (6 month contractors will have taxes taken out)
* Location: Iraq
* Start date: ASAP with 2 weeks training (one in Washington DC and another in Ft. Bening GA)
* # of Openings: 1

Summary:A principal Department of Defense agency is looking for programmers, developers or coders to code, support field deployment and maintenance of a new database application which will be used by Army units in Iraq. Scope These are full-time positions (12/7) located at one of the major US Bases in IRAQ. Deployment will be period of 6-12 months. Training on the application software will begin prior to deployment and will take place in Virginia. These positions are available for full time employment or for independent contractors. These positions are available now.

source: ajaxian.com

ZK Roadmap for 2007

Tom Yeh over at the ZK project has released his roadmap for 2007. It's an intriguing list of tools, features, and developer support:

  • Expanded support for data binding.
  • A visual design tool for Eclipse.
  • Support from mobile platforms: ZK Mobile, a Java ME client, will be released in the first half of 2007.
  • To work with existing applications more efficiently, ZK components will be available in the form of JSP tags. Maybe also as JSF components.
  • Support for browsers without Javascript.
  • Support for other scripting languages than Java, such as Groovy and Ruby.
  • ZK books and more online tutorials.
  • "Mega" components, such as spreadsheets, forums, etc.

Lots of good stuff, especially the news about ZK Mobile and the visual design tool.

One thing I'd like to see happen with ZK (and Echo2, the other, similar server-side framework), is the development of something similar to the Spring Rich Client framework. What is Spring Rich Client?

The Spring Rich Client Project (RCP) is a sub-project of The Spring Framework. Spring-RCP's mission is to provide an elegant way to build highly-configurable, GUI-standards-following rich-client applications faster by leveraging the Spring Framework, and a rich library of UI factories and support classes. Initial focus is on providing support for Swing applications but a goal of Spring-RCP is to be view agnostic as much as possible.

Both ZK and Echo2 resemble desktop GUI frameworks, and thus could benefit in the same way as Swing. In fact, if Spring-RCP is truly view agnostic, it might make sense to try to use Spring-RCP directly.



source: ajaxian.com

GWT 1.3 Released

The first open source release of the Google Web Toolkit has been announced.

Version 1.3 is the first to be released with the new open process:

Our open source charter, "Making GWT Better," explained that GWT development would take place in the open, and that we'd even publish our engineering meeting notes. We're happy to report that it's working out really well. We've had many fruitful discussions on the contributors forum, and we've already received and accepted some patches that will make it into the next version of GWT.

As part of the open process you can dip into the development plan for 1.4 which includes items such as:

  • New widgets: RichText, CollapsiblePanel, DateFormatter, ColorPicker, and more.
  • Development: True JS output, new Java classes, line precise reporting, and more.
  • Performance: simple inlining, dead code elimination, optimized bootstrap, and more.
  • Fixes: IE issues, Linux issues, and more.
source: ajaxian.com

Why choose Dojo

Choosing a platform for your Ajax applications isn’t a trivial task. There are more choices than you have had hot dinners, and new ones pop up on a daily basis. If a framework wants adoption, it helps to have a story on why a developer should choose that library.

Dojo has just gone out and written up its thoughts on why you may want to choose their framework, which includes the following analysis, and a set of comparisons to Prototype, jQuery, Ext, MochiKit, GWT, and YUI. Give it a read, and let us know your thoughts.

Breadth and Depth: Dojo is the “full stack”. Instead of cobbling together components from several different sources, Dojo allows each component to build on a trusted set of high-quality building blocks by providing integrated infrastructure and a wide variety of optional modules. These components provide good solutions to common user experience problems and can be easily tweaked to meet your needs. From pane-based layouts to client-side charting and graphing to data binding to a time-tested module system, Dojo is solid infrastructure for delivering great experiences.
Quality: Infrastructure for internationalization and accessibility is woven through the entire fabric of Dojo. Keystrokes are hinted correctly. The components all fit together as a cohesive whole. Everything is customizable easily with CSS, but very little needs to be tweaked to get a great looking UI nearly everywhere. These are the hallmarks of a system which has been designed and tested to deliver great experiences, not only to users, but also to designers and developers.

Performance: Dojo is used on high-profile, high-traffic sites every day and Dojo’s build tools are a key reason why. Dojo’s package system makes it easy to manage large-scale UI development projects and the build system layers on top to make your applications scream; all without code changes. Dojo also packs high-performance implementations of common utilties into its core, and the rebuild of Dojo for 0.9 focuses heavily on performance and reduced code footprint. The result is a small, tight toolkit that is blazing fast. Dojo’s performance alone makes it an ideal platform to extend and build on.

Community: Dojo is an open community. As a result many individuals and companies have been able to come together on a level playing field to build tools that benefit everyone. The licensing of the toolkit is designed to be as apolitical as possible and we work hard to ensure that getting your itches scratched is easy if you are willing to get involved. All development happens in the open and the barriers to entry are intentionally very low. We don’t care where you work or how “qualified” you are, all we care is that you want to build products that makes user experiences better. Designer or developer or doc writer, the community Dojo values contributions of every kind and position in the community is commensurate with the quality of the work you do, not political wrangling. We’re working to change the notions of who can be contributors in Open Source and we invite you to join us in charting a new path. If you want to build a great product and think you can help us, we want to hear from you.


source: ajaxian.com

Saturday, August 4, 2007

Google Mashup Editor powered by GWT

I sometimes get asked “why doesn’t Google eat it’s dogfood and use GWT”. I normally point them too:

  • GWT has been out for just over a year (> 1 million downloads), so it is obvious that properties from 4 years ago may not be running GWT :)
  • There are several parts of Google that do use GWT (such as Base)
  • Just because we offer an open web toolkit doesn’t mean that it is the right tool for every web application out there.

We are starting to see more and more applications from Google make it out with a “powered by GWT” sticker. One high profile case is the new Google Mashup Editor which actually consists of three distinct parts:

  • The Mashup Editor, which is itself an Ajax application.
  • A server-side hosting framework, which provides developer services (e.g., source code management via Google Code project hosting) and mashup services such as Google Base and a data store that can be accessed via feeds.
  • A JavaScript client library that implements the mashup UI controls and data processing functionality. The server-side components leverage Google’s scalable infrastructure and provide access to Google services via the Google data APIs protocol; the client-side components were developed exclusively using the Google Web Toolkit.

Rich Burdon, of the Google Mashup Editor team, wrote about why GWT was chosen. Here is a closer look:

Before starting the project, our team already had a lot of experience building complex AJAX applications by hand — and had experienced many of the problems associated with this approach. Here are some of the reasons why we chose to use GWT rather than rolling our own native JavaScript framework this time around:

  1. Tools matter. As a veteran of the long-ago vi versus emacs debates, it’s interesting to see the same enthusiasm go into the Eclipse vs. IntelliJ IDE arguments. Whichever side you’re on (I fought for the latter in both cases, but we have members of both camps on our team), tools can make a huge difference in terms of developer productivity. You used to think twice before refactoring a large component that needed attention; having the tool take care of these kinds of complicated, repetitive (and error-prone) tasks makes life easier and can lead to better quality.
  2. OO is a good idea. I remember figuring out how to make JavaScript objects polymorphic and finally understanding what a closure is. Indeed, my colleague Stephan Meschkat, who works on the Maps API, often reminds me of JavaScript’s inherent power and elegance. However, I like to have keywords like “interface,” “private,” and “final” at my disposal — even better to have my compiler (and my editor) remind me that I’m attempting to call a function with inappropriate arguments. Type safety saves debugging time, and OO abstractions can help to reduce complexity in your code.
  3. Compatibility. Java’s original slogan of “write once, run anywhere” fell victim to the intense competition between browser developers. Although JavaScript, being a smaller core language, has fared somewhat better, the complexities of juggling different DOM implementations over a growing number of browser platforms makes writing cross-platform AJAX components difficult. GWT’s ability to insulate you from much of this complexity probably makes it a no-brainer for this benefit alone.
  4. The client is only half the story. Both the Mashup Editor and the resulting mashups themselves interact with Google services; being able to code both sides of a remote method call in the same language has some obvious benefits. Aside from the relative simplicity afforded by the GWT RPC mechanism, both client and server components can share constant definitions and in some cases, simple functions.
  5. Open systems are less scary. A programming framework is something that introduces abstractions. The benefits include making complex concepts simple and quicker to implement; the downside is that if you want to do something that the framework wasn’t designed for, you’re on your own. It was important for us to be able to get under the hood and tweak the native JavaScript. For example, the Mashup Editor’s template-processing functionality uses a native JavaScript library that we borrowed from the Google Maps API.

Thursday, August 2, 2007

Stuffing more Ajax in the Backpack

Backpack, the simple web-based manager of to-dos, notes, ideas, and schedules from 37 Signals, has had an upgrade.

The team discussed some of the changes, and the biggest addition is the ability to move any “widget” (note, to-do list, picture gallery, etc.) anywhere on the page, or even to another page.

We talked to Sam Stephenson, also of Prototype acclaim, to get his thoughts on the changes, and what we may see in Prototype and Script.aculo.us coming out of this practical work. He gave us some detailed thoughts, and posted them on the 37 Signals blog:

Sam on Backpack

Under the hood, Backpack’s Pages tab has been completely rewritten. We moved nearly all of the application’s UI logic out of hand-written JavaScript files and into Ruby using RJS templates. This resulted in approximately 1600 fewer lines of application JS, and let us deliver pages with substantially less markup, since the edit states are now loaded on-demand instead of included in bulk with each page load. In addition, we’re running Backpack on the latest versions of Rails, Prototype, and script.aculo.us from SVN.

Most of the custom JavaScript in the new Backpack is used for wiring the interface in reusable ways. We’ve built a handful of mini-libraries that sit on top of Prototype and script.aculo.us, and we’re using them in several of our other applications in addition to Backpack.

One of these libraries adds support for specifying a CSS selector for script.aculo.us Sortable containment. It uses Prototype 1.6’s new Function#wrap to add the behavior in an aspect-oriented way without modifying the original Sortable source code. This is the library that powers Backpack’s widget reordering. It’s currently being used in Backpack and Basecamp.

Another library, internally called Hover Observer, uses an unobtrusive technique (monitoring the entire page for mouse movement) to add and remove a “hover” class on element hierarchies with certain class names. Combined with CSS, this allows us to easily show the edit/delete/move “nubbins” when you mouse over widgets on the page, or show drop-down menus when you mouse over applications in Open Bar.
The library also lets us specify enter and exit delays, so if you accidentally mouse outside of a target area, the hover class isn’t removed immediately. Think of it as a cross-browser implementation of the :hover CSS pseudo-class, on steroids. Hover Observer was developed for Backpack and is now being used in Basecamp and Highrise.

The last library is tentatively known as Transitions, and provides an extremely simple API for animating transitions between DOM states. The animation resizes and fades an element’s content from one state to another, much like the effect you see when switching preference panes in OS X System Preferences. You’ll see the effect when you edit any item in Backpack. Because the API is simple, RJS-compatible, and easy to integrate into existing applications, we were able to develop it and drop it into Backpack in a single weekend.

I’m extremely pleased with how everything turned out, and I’m looking forward to open-sourcing as much of our JavaScript infrastructure as possible in
the very near future. If you have a Backpack account, I hope you’re pleased with the changes, too. :)

Bubble 2.0

The sky is falling! Every publication has to have it’s resident curmudgeon. It’s a franchise, and PC Magazine’s is held down by John Dvorak. Now he’s moaning about a dot-com bubble redux involving Web 2.0 based companies.

Each of these bubbles had a distinctive theme. For the dot-com bubble, it was e-commerce—it really should have been called the e-commerce bubble. Everything was focused on how the Internet was going to destroy all existing brick-and-mortar operations. We were told that you’d be buying sandwiches over the Internet and having them delivered the next day by FedEx. Everything was about “eyeballs” and finding ways to attract customers, whether they bought anything or not. Every article in every newspaper in the country parroted the litany as to how you’d be out of business in a year or two if you were not present on the Web in a big way. Of course, this was all crap.

The current bubble, already called Bubble 2.0 to mock the Web 2.0 moniker, is harder to pin down insofar as a primary destructive theme is concerned.

He goes on to scoff at the various concepts that are in vogue in the Web 2.0 space, all of which could come tumbling down in a crash.

  • Neo-social networking
  • Video mania
  • User-generated content
  • Mobile everything
  • Ad-leveraged search
  • Widgets and toolbars
An economic bubble is defined as “trade in high volumes at prices that are considerably at variance from intrinsic values”. Is that really where we are? I don’t see all that many “me too” or momentum investments in Web 2.0 companies — just a $10 million investment here or there by some VC’s. Facebook has a large valuation because they actually generate lots of advertising income (shoot, 1% of all online time is spent on Facebook), and online advertising it here to stay.

Most of the Ajax/Web 2.0 activity I see right now is existing companies retooling their online presence to take advantage of some of the new technologies and ideas.

Sorry Dvorak, no bubble here yet.

source : ajaxian.com

Monthly Ajaxian Roundup for July, 2007: iPhone and the Plugin Wars

The summer is traditionally a slow time, but this July had some fun happenings. The iPhone buzz continued, and Episode 2: The Plugin Wars continued. Mozilla announced that their front was moving the battle to enemy territory. Brendan Eich said, “If we fight them over in IE, they won’t come fight us over here” ;) He then launched his Iron Screaming Monkeys and Microsoft retaliated by hinting that “for performance reasons” they may have to take out the scripting host in future versions of IE.

iPhone

Frameworks

Dojo

Script.aculo.us

ExtJS

Yahoo! UI

jQuery

JavaScript

Offline

CSS

Browsers

Tools

Showcases

source: ajaxian.com

Wednesday, August 1, 2007

XRAY: Peer into your web pages

John Allsopp has developed XRAY, a bookmarklet that launches a tool to visualize the web page that you are on (a little like features in Firebug and Firefox). The look and feel is great, and the margin popups look like the new Safari/Webkit search functionality (mmm orange).

What is XRAY

XRAY is the first in hopefully a suite of free cross browser tools for helping web designers and developers better visualize what their code is doing in a browser. XRAY is designed to help you get beneath the skin of your web page.

XRAY let's you see the box model for any element on a page in action - where is the top and left of an element, how big is each margin, how big is the padding, how wide and high is the content box?

What platforms and browsers is XRAY available on?

XRAY currently has been tested on Safari 2 and 3 on Mac OS X, Webkit nightly builds, and Mozilla based browsers (Firefox, Camino and so on) on Mac OS X and Windows. At present it won't work on Internet Explorer (XRAY uses the canvas element, but plans are afoot to adapt it for Internet Explorer), and has not been adapted for Opera. We hope to have versions for Opera shortly, and Internet Explorer on Windows in the not too distant future. XRAY works in Safari 3 on Windows, but clicking a bookmark does not fire any Javascript it contains. To use XRAY on Safari 3 for windows at present, you'll need to paste the XRAY link into the address field and hit return.




source : ajaxian.com

YUI 2.3 Released: Rich Text Editor, Components, and Themes

YUI 2.3 has been released with six new components, as well as a skinning architecture and a new look for the components.

Features

  • Rich Text Editor: Cross-browser support has always been a major challenge for RTEs, and we think you’ll be impressed with how well this editor works across the various environments. You can instantiate it with just a few lines of code for simple implementations
  • Base CSS: Nate Koechley continues to extend and refine the YUI CSS foundation. Base CSS itself applies consistent and common style treatments for the foundation
  • YUILoader: A mechanism for loading YUI components (and/or your own custom components) on the page via client-side script.
  • ImageLoader: Allows you to defer the loading of some images to speed initial rendering time on your pages.
  • ColorPicker: The Color Picker provides a powerful UI widget for color selection, featuring HSV, RGB, and Hex input/output and a web-safe color-selection swatch.
  • YUI Test Utility: YUI Test introduces a flexible unit-testing framework for the YUI ecosystem and serves as the foundation for our own unit-test battery.
  • Skins





source : www.ajaxian.com