Monday, July 31st, 2006
Job Description:
Hot young startup backed by corporate money is seeking a Front End User Interface Programmer/Designer with a demonstrable track record.
Job Responsibilities:
Build and maintain companies front end, and help design, manage and implement new features.
Job Qualifications:
BS or advanced degree in Computer Science
2+ years experience in front-end design
Expertise with Ajax, Flash, PHP
Experience with tiered web applications
Familiarity with Web 2.0 concepts
UNIX/Linux experience on x86 platform is a plus
The position is located in Manhattan, NY. Please forward your resumes to aw@sap8.com. No third parties please.
Category: IE
, Browsers
The IE 7 team just let us know that IE7 is to be distributed via Automatic Updates!:
As we get close to the final availability of Internet Explorer 7, I want to provide an update on our distribution plans. To help our customers become more secure and up-to-date, we will distribute IE7 as a high-priority update via Automatic Updates (AU) shortly after the final version is released for Windows XP, planned for the fourth quarter of this year.
This doesn’t mean that the old IE’s will disappear in short order, but it nice to see that we may see a quicker uptake to IE 7 than past releases.
Category: Web20, Mobile
On the Web 2.0 Journal today, there’s a new article from Ajit Jaokar asking for a real definition of what “mobile web 2.0″ really means.
I see Web 2.0 as the Intelligent web or ‘Harnessing Collective Intelligence.’ Mobile Web 2.0 extends the principle of ‘Harnessing Collective Intelligence’ to restricted devices. The seemingly simple idea of extending Web 2.0 to mobile Web 2.0 has many facets.
He lists out these facets - restricted devices, building for these devices, and what characteristics can be learned from them. He defines restricted devices in several ways including having one or more of these characteristics - easily carried, battery driven, limited input means, but not wearable.
He gives the iPod as a reference to show a good web/local PC model for mobile devices, a PC-powered interface to provide mobile content to a portable, easy to use device. This is more of a static idea than most think of when they think “mobile web 2.0″. More often, they think of methods to use things such as Ajax in a cellphone’s web browser. He suggests, though, that this is not “mobile web 2.0″ - it lacks the user generated compontent.
Category: Dojo, PHP, Programming
Alexander Netkachev shows, in this new post on his site, how to create an Ajax-based login page with the help of the Dojo library and a new offering from Zend - the Zend Framework. The Zend Framework is a MVC-based framework written in PHP.
A few days ago I understood the right usage of the framework. Frankly speaking, it does not help with creating Web forms—it has no high-level complex components like TDataGrid in PRADO or even Repeater in ASP.NET. And what I understood is that it is not Zend Framework’s business how developers are creating their forms and here is a reason for this: modern pages are created with a lot of JavaScript and, I believe, are created with client-side components, not server-side.
He set this mission before himself - to create a lightweight Ajax form combining Dojo and the Zend Framework in the easiest way possible.
He assumes you already have both libraries installed (both relatively simple to get working) and gets straight to the code. First off is the creation of the view for the login form itself, the place where the Dojo toolkit is included and the Javascript functionality lives - as well as the simple login form. Next up is the controller for the PHP side, with three actions - a default action, one to perform the login, and the other to show a success message. Finally, there’s the Dojo javascript to make the request to the backend and the PHP script to validate if the username and password are correct.
Friday, July 28th, 2006
Category: XmlHttpRequest, IE
MS announced this week that IE7 will be pushed as a high-priority update, so we can expect it to be popular pretty quickly. Reader Shawn Lauriat brought our attention to the question: How native is IE7’s XMLHttpRequest?
The IE team have promoted the new IE7 as including native XMLHttpRequest. This is the case, insofar as you can instantiate an XHR using new XMLHttpRequest(). More importantly than the syntax, XHR will still work when ActiveX has been disabled (unlike IE6 and below).
On the other hand, Shawn notes that some issues exist. Some have pointed out that its more of a native facade than a native Javascript object. Specifically:
- xhr.prototype fails. Indeed, it’s reported that any dynamic member creation fails (e.g. xhr.callId = 25; an idiom that can be useful for Call Tracking). If this is still the case, it’s not the behavior of a native object and it’s not consistent with other browsers.
- It’s also worth pointing out that IE has an option to disable native XHR. (Aside: can we switch to positive terminology already - “enable” rather than “disable” … it’s hardly a secret of HCI that options should be stated in the positive :-/). The XHR option is, reasonably enough, motivated by security. Although it sounds like XHR will default to enabled (sorry, “not disabled”), it’s still a reality that some users will be continue to be lost if you rely on XHR. Don’t throw out that IFrame just yet!
IE7 XHR - Native or Not?
Category: Ajax, Utility
Fred Anderson pointed us to Aptana, a new web IDE based on Eclipse.
They provide some nice screencasts of the functionality, and in the documentation they list “hot-To’s” for Many of the frameworks.
Features
- Code Assist on JavaScript, HTML, and CSS languages, including your own JavaScript functions
- Outliner that gives a snapshot view of your JavaScript, HTML, and CSS code structure
- Error and warning notification for your code
- Support for Aptana UI customization and extensions
- Cross-platform support
- Free and open source. (Source available soon)
Category: Ajax, Editorial
In his latest blog post, Eric Pascarello asks the question “Is Ajax development slowing down?” Is the shiny new coating of this revolution in web development finally wearing a bit thin, causing people to move on or not innovate like they used to?
I was asked an interesting question by a friend the other day. “Is Ajax development slowing down?”
I noticed the same trend; I just did not really think that it was a big issue. It seems that there is a slow down in the amount of information that is coming out on the net.
He doesn’t seem to think that there is a real slowdown in Ajax development, it’s just a perception. He gives four reasons why this seems so:
- It is SUMMER in the northern hemisphere! (more outside, less inside = less code)
- Seems like frameworks are maturing and that people are fully developing applications before they release them.
- Seems like people are focusing on more of the technical issues of Ajax now and not the wow factors.
- It really seems like new developers in the realm of Ajax are taking their time looking at what Ajax has to offer. They are looking at frameworks versus a custom solution.
Thursday, July 27th, 2006
Category: Ajax, Programming
Kevin Yank, SitePoint’s “reporter in the field” at this year’s OSCON has a new post on the SitePoint Web Tech blog with information and his impressions about a talk given by Joseph Smarr, a Plaxo developer on cross-site Ajax.
Mashups, if you’ve been living under a rock, are web applications built by combining services provided by several specialized web applications, typically using AJAX as the glue. One of the main challenges faced by developers of mashups is the same-origin policy, which prevents JavaScript on one site from contacting other sites as a security measure. For mashups to really work, developers need to find a way around that restriction.
Kevin talks about some of the solutions that have been found to the problem - a server-side proxy, a Flash application proxy, JSON-P - but all have issues surrounding their use. They don’t quite fit in elegantly with the rest of the strong, flexible code around them.
So, is there a solution? Does Plaxo have the answer? They might, but it’s still a bit of a work in progress. As Kevin calls it, it’s a “Javascript wormhole”, a method to tunnel through pages when a service is called and closed when done. There’s even a suggestion of how it might flow, using iframes and callbacks to make it happen. There are still issues surrounding it (not just in its creation, but in its use), but things are looking brighter.
Category: JavaScript, Library, Prototype
Aaron Newton, Product Manager at CNET sent us an email about his issues of using Prototype in production at a large company like CNET:
I've made a lot of use of Prototype but using it has been a bit of a controversy here at our network. Specifically, the extensions that are inherent in Prototype often create problems for (poorly written) legacy code and advertising javascript that we must include in our environment to make a buck.
Because it's not reasonable for our technical producers to regress every ad that runs on our site, I hired a good friend (and far more talented programmer) to help me find a solution. He, one Alex Cruikshank, authored a chunk of code (2.25K) for us that I think could be of great use to those out there who avoid Prototype because of the way it alters Arrays and Objects; specifically, those trying to use your library in an environment where they do not control 100% of the javascript included.
The code, all 3K of it, is a wrapper of sorts that removes all the extensions to Array and Object from Prototype. Then, when you want to make use of Prototype, you just apply this wrapper to your code.
We have put the code up for Prototypify along with the documentation.
JAVASCRIPT:
-
-
Prototypify = function() {
-
-
}
-
-
Prototypify.prototypified = false;
-
-
// store then remove functions from prototypes of native objects
-
Prototypify.arrayFunctionHolder = new Object()
-
for (x in Array.prototype)
-
{
-
Prototypify.arrayFunctionHolder[x] = Array.prototype[x];
-
delete Array.prototype[x];
-
}
-
-
Prototypify.stringFunctionHolder = new Object()
-
for (x in String.prototype)
-
{
-
Prototypify.stringFunctionHolder[x] = String.prototype[x];
-
delete String.prototype[x];
-
}
-
-
Prototypify.numberFunctionHolder = new Object()
-
for (x in Number.prototype)
-
{
-
Prototypify.numberFunctionHolder[x] = Number.prototype[x];
-
delete Number.prototype[x];
-
}
-
-
-
Prototypify.proxy = function( f, proxyArguments )
-
{
-
return function()
-
{
-
var needsPrototypes = ! Prototypify.prototypified;
-
if ( needsPrototypes )
-
{
-
Prototypify.prototypified = true;
-
for (x in Prototypify.arrayFunctionHolder)
-
Array.prototype[x] = Prototypify.arrayFunctionHolder[x];
-
for (x in Prototypify.stringFunctionHolder)
-
String.prototype[x] = Prototypify.stringFunctionHolder[x];
-
for (x in Prototypify.numberFunctionHolder)
-
Number.prototype[x] = Prototypify.numberFunctionHolder[x];
-
}
-
-
if ( proxyArguments )
-
{
-
for ( var i=
0; i <arguments.
length; i++
)
-
if ( typeof arguments[i] == 'function' )
-
arguments[i] = Prototypify.proxy( arguments[i], proxyArguments );
-
}
-
-
var out = f.apply( this, arguments );
-
-
if ( needsPrototypes )
-
{
-
for ( x in Array.prototype )
-
delete Array.prototype[x];
-
for ( x in String.prototype )
-
delete String.prototype[x];
-
for ( x in Number.prototype )
-
delete Number.prototype[x];
-
Prototypify.prototypified = false;
-
}
-
return out
-
}
-
}
-
-
Prototypify.instrument = function( clazz, proxyArguments )
-
{
-
for ( prop in clazz.prototype )
-
{
-
if ( typeof clazz.prototype[prop] == 'function' )
-
clazz.prototype[ prop ] = Prototypify.proxy( clazz.prototype[ prop ], proxyArguments );
-
}
-
}
-
-
Prototypify.instrumentStatic = function( clazz, proxyArguments )
-
{
-
for ( prop in clazz )
-
{
-
if ( typeof clazz[prop] == 'function' )
-
clazz[ prop ] = Prototypify.proxy( clazz[ prop ], proxyArguments );
-
}
-
}
-
Copyright (c) 2006 CNET Networks, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Category: Examples, Articles, Programming, TIBCO
Brian Walsh has written an exceedingly well documented tutorial on combining Spring MVC, XStream and TIBCO GI. The focus is on using GI at the view layer while making only incremental changes to an existing Spring MVC application (the application from the Spring MVC step-by-step tutorial in this case, which you'll have to step through before you go on to the GI tutorial):
Application owners and developers alike predictably want to increase productivity and reduce time to market. This type of rapid implementation gives us several imperatives:
- No wholesale replacement of our Spring investment.
- Incremental change of existing server code as opposed to wholesale change to, for example, SOAP Web services
- Continued support for non-Ajax clients
- Re-use of existing code wherever we can. Develop the GI application along side the JSP layer.
Since GI generates the view at the client, Spring need no longer generate HTML at the server. Instead, we'll modify our Spring configurations such that Spring can also return raw data in form of XML that can be consumed as a service by the Ajax processes in GI.
The tutorial is generously illustrated with sequence diagrams, annotated configuration files and screen shots. It shows how to replace the HTML rendering logic of the existing application with an XStream-based logic that transforms the model into XML. (If you haven't looked at XStream yet, you really should. It's a clever library that allows you to serialize and deserialize objects to and from XML with a few lines of code.) All of the rendering is handled by GI in the client now, including degrading gracefully for non-AJAX clients.
The tutorial also serves as a lesson in how the development of web applications will change when WYSIWYG, component GUI interface tools become involved. The story board before-and-after shots of the UI in particular suggest some of the artifacts that might be produced in legacy web to AJAX migrations.
Category: JavaScript, Tip
Alexander Kirk has written about a problem with XHR, responseXML and document.domain in FireFox:
This will work in IE, Safari, and Opera.
This will not work in Firefox 1.0. This is very awkward but at least it has been fixed in 1.5.
So it will work in Firefox 1.5. But:
The responseXML object is useless. You can’t access it, you receive a Permission Denied when trying to access it’s content (e.g. documentElement). Very annoying.
Even stranger that responseText is still readable. What’s the reason for this? Is there some security risk i am unaware of or is it a plain bug?
As the responseText is available there is a pretty simple fix: re-parse the XML, which is kinda stupid and cpu intense if you have a lot of them. (something like: var doc =
(new DOMParser()).parseFromString(req.responseText, “text/xml”);)
Category: Books
The "Ajax Design Patterns" book is now out and I've added some overview info to the AjaxPatterns wiki. It's published by O'Reilly, written by myself (Michael Mahemoff), and consists of 655 pages with 70 patterns and introductory material.
- Part 1: Introduction
- Chapter 1: Introducing Ajax. Expains how Ajax came about, overviews the technology, and identifies current trends.
- Chapter 2: A Pattern-Led Tutorial. Try the tutorial apps online. The first half contains three exercises walk you through the Foundational Technologies and are suitable for readers who haven't yet worked with Ajax. Each exercise focuses on one Foundational Technology chapter - manipulating the user interface, responding to user actions, communicating with the server. The second half starts with a conventional web application (Ajaxagram, an anagram finder) and each section introduces some patterns to refactor it into a full-fledged Ajax App.
- Chapter 3: Ajax Design: Principles and Patterns. Discusses the theoretical foundations for the Ajax patterns - what constitutes a quality design, what problems do designers encounter, and how do they overcome them?
- Part 2: Foundational Technologies. 11 "building blocks" describing the raw technologies underlying any Ajax App.
- Part 3: Programming Patterns. 23 patterns guiding on performance and maintainability, covering topics such as browser-server message formatting, caching, and strategies for DOM population.
- Part 4: Functionality and Usability Patterns. 28 patterns on the things that matter to users, including widgets, drag-and-drop, and bookmarkability.
- Part 5: Development Patterns. 8 patterns advising on best practices such as debugging and testing.
- Extras: The inner covers contain an alphabetically ordered list of patterns, each with a one-line summary and a page reference. The appendixes cover: Ajax libraries and frameworks, setting up the code examples, discussion of patterns and pattern languages, and references. Each pattern contains an "In a Blink" thumbnail sketch to help you grasp the concept at a glance (or, in a blink) and annotated screenshots for the Real-World Examples.
I've been talking about the patterns on my podcast and there will be full audio for each pattern available by the end of August, if you're into that sort of thing. The book came out earlier this month and is available now at Amazon.
In related news, I noticed APress has a ton of new Ajax books coming out this month (six to be precise), which triggered this new wiki page of Ajax books to collect all the resources out there.
Category: JavaScript, Conferences
Whether you're a "back to basics" kind of person or are just starting out and want to catch up quick on your Javascript skills, you might want to check out this great resource from a talk/tutuorial given by Amy Hoy at this year's OSCON - a Javascript Boot Camp.
Even though AJAX wouldn't ever have become so popular if the Javascript world hadn't suddenly exploded with mature development and testing tools, there's little information on how to be a really good Javascript programmer. This talk is for everyone who feels their Javascript skills just aren't up to snuff.
She's provided all of the materials in the post on her website, including:
- Downloads - the source code and the slides (PDF)
- Links to specific libraries mentioned
- Web site reference links
- Del.icio.us tagged items for Javascript and this tutorial
Category: Presentation, Conferences
On the SitePoint Blogs today, "live" from this year's OSCON, there's a new post covering the talk from Kevin Henrikson concerning how to squeeze the most out of your Ajax connections - a few handy optimization techniques.
Kevin Henrikson of Zimbra gave a brisk presentation covering some of the lessons his organization has learned and the “dirty tricks” it has implemented to improve the performance of web applications that rely on large JavaScript/CSS codebases. Here’s a quick run-down of the items he covered. The slides of the talk are up on the Zimbra blog.
Among the tips mentioned are:
- using a web page analyzer to find the trouble spots in your pages
- Javascript compression tools to reduce the size even more
- properly structured HTML to make for faster rendering times
The post also mentions two of the case studies Kevin did - one centered around a blog post he did on optimization and the other on lala.com. Check out the slides for the full story...
Wednesday, July 26th, 2006
Category: Comet
Adding on to the last post on cross domain XHR, Cometd now supports working across domains, without plugins.
Alex Russell explains:
By building on top of the Dojo ScriptSrcIO infrastructure it was trivial to make a JSONP transport for Cometd. We just adapt the long-poll style of Comet but make the initial handshake messages JSONP-clued. That in place, the rest works just like “normal” long-polling, except that the client can connect from any domain. The configuration problem just dropped from “make sure everything cooperates at the systems and network level” to “make sure that the client and server speak the same protocol”…and I like solutions that put the problem in software and not external configuration or human effort.
So what’s the downside? The first downside is that the latency characteristics for cross-domain Comet using this technique are the same as long-polling. Not bad, mind you, but not as optimal as iframe, multipart-mime, or Flash-based solutions when you have large numbers of messages being thrown at the client. Additionally, it’s more difficult to know when a connection “times out” or in some other way fails, but I think these are tractable. Having a Plan A and a Plan B for cross-domain Comet and a server that can speak both styles via pluggable transport wrappers is exciting to me. By lowering the configuration barrier, I think we’ll start to see a significant uptick in Comet adoption.
Category: Articles
Peter Nixey has written a piece on his frustrations with the lack of cross domain XHR in his current applications.
Clientside cross-domain data requests are an extremely useful tool. They can only currently be done (in Javascript) using the script-tag workaround to deliver data as JSON.
External JSON is extremely dangerous as it is arbitrary third-party code executed in the scope of the current web-page. It can be used to steal passwords or data present in the current scope. JSON is also a non-generalised data standard and requires new server-side libraries and code.
XML is already a data standard in wide use with API's present in most programming languages. It's inert, human-readable and highly compressible using gzip.
Any cross domain XHR must be server opt-in (rather than opt-out) or else we leave all non-enabled servers vulnerable to brute-force attacks.
Agreement can very simply be communicated by having the server send a header authorising cross-domain use of the data.
... any thoughts?
—
Next Page »
