Wednesday, March 30th, 2005
Category: JavaScript
Michael Moncur has spoken about the concerns wrt security with GreaseMonkey.
I understand that people get concerned when they think of scripts running wild on their system.
However, like Michael, I also find it ironic that many of the same people are 100% ok with installing firefox extensions, or grabbing the latest Cool Toy from the internet.
There are simple rules:
If you want to be safe. Install nothing.
If you want to install cool features, you have to trust where it came from.
Sunday, March 27th, 2005
Category: Ruby
The latest update to Rails has more great Ajax features:
The Ajax wave is sweeping across Rails. In this release, we’ve added a :position option to both link_to_remote and form_remote_tag that can be set to either :before, :top, :bottom, or :after. These options make it possible to add new DOM elements to existing lists without replacing the whole list. When working on big lists that are in a fixed order anyway, there’s a considerable speed increase to be had.
Yellow Fade Technique
Additionally, we’ve implemented the first in a hopefully long series of packaged effects. This is the 37signals’ Yellow Fade Technique that’s now available as Effect.Highlight(id) — perfect for highlighting a new element that was just added with Ajax. If you have the Javascript chops to do other effects, please do help out. The wiki discussion page for Ajax in Rails already has great ideas for slide, fadeout, and squish.
Friday, March 25th, 2005
Category: Java
Tapestry is an event-based Java web framework. It is very component oriented, and many think it is what JavaServer Faces should have been ;)
It is natural for Tapestry to have components which grok Ajax, and we already have some coming.
For example: This example is Google Suggest-ish.
The more the merrier!
Category: JavaScript
Do you want to go annotation crazy in the JavaScript world? Anders Norås has created annotation support in JavaScript.
He follows the XDoclet-style approach, in that annotations are tacked on via comments:
Calculator.square=function(num) {
/**
*@Version(“1.0.0�)
*@Modifiers(modifiers=Modifier.static|Modifier.public) *@Returns(type=�number�,description=�The square of the given number�)
*/
return num*num;
}
and then you can get at the annotation data via:
var version=Reflection.getNamedAnnotation(Calculator.square);
alert(“Major: “+version.major+'\n'+
"Minor: “+version.minor+'\n'+
Maybe the next ECMAScript will have true annotation support as part of the language? Does it matter as much in JavaScript?
Thursday, March 24th, 2005
Category: Ajax, Java
Echo is a Java Web Framework. Now, a new version of the framework, Echo2 has been released (in experimental/alpha mode).
It has some interesting Ajaxian features, and you should check out the interactive demo.
Rad the discussion on this from the Java crowd:
Echo2 is a reinvention of the Echo Web Framework
built around an Ajax (Asynchronous JavaScript and XML) rendering
engine. Distributed under the Mozilla Public License, Echo2 aims at
providing a component-oriented/event-driven toolkit for developing web
applications that approach the capabilities of rich clients.
​​​​
​Echo2 uses the array of Ajax technologies in the interest of providing
a more rich-client-like user experience. All client/server interaction
is accomplished over an XMLHttpRequest wire. An entire Echo application
runs from within a single web page - without a reload nor full page
update. User input is sent to the server by POSTing XML documents over
XMLHttpRequests. The server reciprocates with XML messages containing
synchronization instructions, which are then processed by pluggable
client-side JavaScript modules. The net result is a markedly more fluid
and “desktop-like” user experience and a dramatic performance
improvement when compared to traditional web application technologies.
One
way of understanding how the rendering engine works is to watch an
Echo2 application run in “Debug Mode”, which causes all the XML
synchronization messages to be displayed. Debug Mode can be enabled by
appending “?debug” to the URL of an Echo2 application. You can see this
for yourself by visiting the “Interactive Test” application here: http://demo.nextapp.com/InteractiveTest/ia?debug (Please note that running in Debug Mode will cause a substantial performance degradation.)
All
web rendering is performed behind the scenes with Echo2’s entirely
Java-based user-interface toolkit. The end-developer need only be
concerned with the server-side representation of the user-interface.
Echo’s “Web Application Container” monitors the state of the component
hierarchy and takes care of all communication with the client browser.
The Application Container is responsible for processing synchronization
messages from the client, and notifying the server-side application of
user actions via plain Java events. When modifications are made to the
server-side hierarchy of components representing an instance of the
user-interface, the Application Container translates these changes into
an efficient synchronization message sent to the client to bring its
state up to date with the server.br>
The current release of
Echo2 is 2.0 Alpha 3. Please understand that Echo2 is currently in the
alpha stage and is under heavy development. We welcome input and
participation in the project. Please visit http://www.nextapp.com/products/echo2 for more information and downloads. Our Echo community developer forums are also available at http://forum.nextapp.com.
For a sample demonstration application written using Echo2, please visit:
http://demo.nextapp.com/InteractiveTest/ia
Category: Ajax, JavaScript
Matt Raible pointed me to Ditchnet.org which has some interesting JavaScript tips and tricks.
At the top there they discuss enums in JavaScript:
function Suit(name) {
this._name = name;
}
Suit.prototype.toString = function () {
return this._name;
};
Suit.CLUBS = new Suit('clubs');
Suit.DIAMONDS = new Suit('diamonds');
Suit.HEARTS = new Suit('hearts');
Suit.SPADES = new Suit('spades');
It would be a lot nicer to have this in XHR for the status’ for example.
Rather than:
if (xhr.readyState == 4)
you could have:
if (xhr.readyState == XmlHttpRequest.STATUS_READY)
A simple thing, but just gets you away from the ‘hackiness’ factor.
Category: Ajax, JavaScript, Usability
One of the common arguments is whether or not your application “should just work” if the client doesn’t have JavaScript enabled (or an old version etc).
Jep Castelein spoke about this recently.
As always, when you are chosing technology you have decisions to make. One of them is the balance.
- How much time are you able to spend to make the application work seemlessly in non-JavaScript mode
- What is the target audience
- What control do you have over the target audience
- How much work would it be to make a non-JS version? (e.g. do you just have ‘nice to have’ features in JS with easy fall backs? Or are you going crazy UI stuff that is not trivial to implement
There is no ONE correct answer for your application.
Sam Pullara has an interesting solution to the problem. He uses the same full pages for the entire application. When in Ajax mode, he uses a server-side filter which (via XPath) grabs the piece that he wants back on the client. Obviously a trade off, but an interesting thought.
It is interesting to see that GMail has a non-JS version for people to use now. This makes sense.
It will be interesting to see if Google Maps will do the same thing though!
Category: Ajax
The Technical Pursuit guys really like to push JavaScript to its limits.
I don’t envy them really :)
Visit their demo page and start up their ACE client. Crazy stuff :)
Tired of fighting to build effective, efficient, productive web apps? Ready to create web applications that improve your bottom line? Develop where you deploy, in the browser, and make it happen!
TIBETâ„¢ is client-side middleware and WYSIWYG tools for constructing
high-efficiency, high-productivity, highly-scalable web service
clients, web portals,
and standalone or embedded device web applications.
“I am your humble servant, and in awe of what you’ve done with JS.”
– Brendan Eich, JavaScript’s creator and Mozilla project leader.
Wednesday, March 23rd, 2005
Category: Ajax, Editorial, Java, JavaScript, Library
Having a lot of different implementations and innovations is certainly a good thing.
However, many Java web developers are frustrated as hundreds or thousands have sprung up over time. As soon as Servlets and JSPs were released, people realised that they wanted to build a framework at a higher level of abstraction. This lead to pet projects starting up all over.
Some of these projects made their way to opensource. Some are still in use in production apps.
Consilidation has happened, and the JCP is trying to push that ahead even more so with the JavaServer Faces specification. But, people haven’t all been thrilled with its technical merits.
I worry that we face a similar problem in the JavaScript, and Ajax world. We already have many abstraction modules out there. How many people do their own thing to get the browser type etc.
We need to take more advantage of reuse. I want to be able to say:
My current project is using Foo and Bar.
and have it mean the same thing as:
My current project is using Struts and Spring
Part of the game is taking JavaScript developement seriously, and using tools such as Maven repositories to keep track of dependencies and JavaScript modules.
Also, we have the benefit of having frameworks like Rails, JSF, Tapestry, WebWork, ASP.NET etc… all helping us out. This means that developers don’t need to be JavaScript gurus to get simple things done.
Tuesday, March 22nd, 2005
Category: Ajax, Ruby, Screencast
Rails 0.11.0 is out on the street and I’m especially proud of the Ajax support we’ve been able to include. Instead of trying to soften the blow of doing client-side Javascript libraries as many others are doing, we’ve gone ahead and more or less removed the need for hand-written client-side javascript entirely.
This is done by off-loading the creation of DOM elements to the server side, which returns complete constructs that are then injected live through innerHTML. While this method is slightly more verbose than just peddling data across the wire, it’s immensely easier to develop.
And especially the ease of development is critical to the success of Ajax. I used the old style of hand-crafting the DOM on the client-side with Ta-da List and was quite disillusioned at the mess of browser differences and the sheer effort it took. Basically, each sliver of Ajax was a project in itself.
With Honey, though, I’ve been all over the new Ajax style that Rails affords. And what a difference it makes! It’s basically no harder to make something Ajaxed than it is not to, which means that the decision is based on whether its a good fit for the user interface — not on whether we have time to another Ajax project.
It is indeed very cool how they have taken out the need to really WRITE dHTML in your apps.
Read more about this release at: Rails 0.11.0: Ajax, Pagination, Non-vhost, Incoming mail
Check out the movie, which shows you how to setup a form to use Ajax in Rails.
Monday, March 21st, 2005
Category: JavaScript
Lloyd Dalton has a nice little site colr.org, which lets you mess with colors in a del.icio.us kinda way.
colr.org has two purposes:
- It’s a tool to let people fiddle around with colors and words.
- It’s a jungle gym (of sorts) for software ideas
Friday, March 18th, 2005
Category: JavaScript
Mike passed on a link to JavaScript O Lait:
It’s more than just a JavaScript library.
The goal is to ease JavaScript development by building a library of reusable modules and components and enhancing JavaScript with simpler Class and Module handling mechanisms.
“JavaScript O Lait” is free and is covered by the LGPL.
There are some very interesting modules:
- codecs - the string encoding/decoding module
- crypto - cryptography algorithms like rc4 for string encryption/decryption (hashing,/digest coming soon).
- jsonrpc - A json-rpc implementation.
- lang - provides language services like serializing objects to JSON and tokenizing JavaScript.
- stringformat - the string formatting module(loaded with the main module)
- urllib - provides http post, get, .. functionalities.
- xml - provides xml services like parsing, xml2String and importing functionalities
- xmlrpc - an XML-RPC implementation.
The more you look around, the more you see.
Thursday, March 17th, 2005
Category: Ajax
CNet has a new editorial called: Web tools blaze trail to the past.
They have interviewed a bunch of different players, who have interesting opinions.
One of the interesting pieces is:
Passing Fad?
Technologists working on the next generation of Web application technologies scoff at the idea that a JavaScript renaissance is going to threaten their vision of the future. Instead, they insist Google’s rising tide is lifting their boats.
“For a company serving that many people at that scale, Google is taking uncharacteristic risks on their front end to do things that other companies with old infrastructures in place don’t know are even possible,” said Laszlo’s Temkin. “I’m incredibly happy that Google is taking this step, because it’s forcing the market to realize what to us has been incredibly obvious about rich Internet applications. It’s forcing the portals and others to notice the value here. That’s tremendous for us.”
By the same token, Google denies any ideological attachment to its standards-based approach. Instead, the company says it has evaluated all the options before it and will continue to do so as new technologies become available or existing ones get refined.
The JavaScript approach, Google acknowledges, leaves some things to be desired. For example, it’s harder to integrate applications with third-party applications.
In the final analysis, however, Google has given JavaScript that crucial programming designation: good enough.
JavaScript is definitely a pain. It is not the ideal programming model. But right now, with some nice abstractions, Ajax is an interesting choice.
Category: Ajax
“It is really, really, really hard to build something like Gmail and Google Maps,” said David Mendels, general manager of platform products for Macromedia. “Google hired rocket scientists–they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can’t go and repeat what Google has done.”
Google has hired great people. However, I could be wrong, but I don’t think that Adam Bosworth was hacking away at the Google Maps JavaScript. Maybe Josh Block was testing in the different browsers?
I don’t think so :)
Ajax isn’t trivial, but it isn’t rocket science. And, it is only going to get a lot easier. As we look around and see the interesting work that is being done, we are more and more impressed.
Again: We are not trying to say that there isn’t a valid place for Flash, Lazlo, etc.
Category: Ajax
Sam Ruby has written a couple of practices that we should follow in Ajax applications:
- Encoding: the data should first be encoded as octets according to the UTF-8 character encoding
- Idempotency: GET should never be used to initiate another operation which will change state
There are some issues wrt caching GET’s in IE vs. Mozilla.
There is a lot of data located here
Wednesday, March 16th, 2005
Category: Ajax, Ruby
David Heinemeier Hansson and Jamis Buck, are putting Ajax-aware components into Rails.
Jamis is talking about whether to sync, or not to sync….
One of the great benefits to XMLHttpRequest is the fact that you can do work asynchronously. If you can possibly make your UI so it doesn’t ‘hang’, you should do so. However, if you really NEED to block on something for a good reason, then it makes sense to go that route. I normally try to work my UI to handle the asychronous use case as much as possible.
Although the following is easy:
element.innerHTML = submit_request(”/some/action?value=foo”)
If possible, I would really want to make sure that we don’t equate “this is easy” with “this is what we should do”.
Rails simple approach
It looks like Rails is going to have a very simple approach to adding Ajaxian components. The approach marries the world of partials in Rails, and returning arbitary HTML from the server-side, and having the client code innerHTML the responseText.
This covers the 80/20 rule, and gives Rails developers a very simple interface. It also has the benefit of bypassing the pain of the DOM.
There is more though…
While I like having this tactic as PART of the solution, I do also want to see a common set of XML parcels for other common tasks:
- dom-remove: Given an id, nuke it from the DOM
- dom-replace: Given an id, and new content, do a replace
- dom-insert: …
as well as the generic solutions such as:
- Put this HTML at this point
- Run this piece of JavaScript (so the server side can control anything)
The abstractions will be interesting to see. I think there are a variety of levels. One level is something like the Dojo bind(). This is a very low level abstraction about XHR/iframes/… Next we get the web frameworks which will autogen JavaScript for us. E.g. “validate on the server side via XHR” CHECK.
Next Page »
