In essence, his solution allows you to have custom events on application modules and listen to them independent of execution order or availability. Simply using custom events can get you in a pickle if you make yourself dependent on their order. With the decoupling solution proposed by Caridy this becomes one less issue to worry about.
After a lot of hard work, we’re more pleased than ever to present the new version of DOMAssistant: faster, less code, better support and improved stability. And more features, of course.
While we have actually made the code file size smaller, at the same time we have added a number of useful features and improved CSS selector performance.
Along with several fixes, the team added a number of enhancements most notably strong support for Unicode and performance increases for Internet Explorer:
With this release, we wanted to target the world outside our English-speaking box, by adding Unicode support and a complete documentation in Chinese. When that was in place, improving CSS selector performance in Internet Explorer and adding well-needed and requested features was next on the bill.
Happily, we succeded as well as exceeded our goals!”
The newest features include:
Unicode support added, implying support for basically any source document language.
Method cssSelect added to the Core module, to allow CSS selections of an object reference’s children.
Method ajax added for making more customized AJAX calls, with more options.
Method setStyle added to the CSS module.
Method setErrorHandling added to the DOMLoad module.
Method first added to get the first of any matches.
Added support for attribute selectors E[att|=val], E[att~=val], and pseudo-class :lang.
Added support for multiple pseudo-classes, eg. tr:nth-child(odd):not([id]).
Added support for nested pseudo-classes within :not, eg. tr:not(:first-of-type).
Added full compliance for the an+b expression in :nth-child and :nth-of-type, including negative a.
Significant CSS selector performance improvement in Internet Explorer.
Updated documentation in Chinese.
DOMAssistant 2.7 is available for download via SVN or HTTP and is released via MIT license.
Client-side Echo applications do not require an application server, and can also be run entirely offline.
With Echo3, the formerly server-side-only component framework has been recreated in client-side JavaScript. This was not a direct “port”, but rather a re-imagining of the framework with the ideals of JavaScript development in mind. For example, the client-side version of the framework takes advantage of JavaScript’s object and array literal syntaxes to create a capability called “hierarchal component construction”, where an entire hierarchy of components can be created in a single call. Such code winds up being extremely readable, as, when naturally indented, it resembles the component tree.
Core.js framework
A low-level framework, called “Core.js” was created to ease development of object-oriented and event-driven code in JavaScript. Core.js provides an inheritance model for building JavaScript objects using class-based (rather than prototype-based) inheritance. It additionally offers the capability to specify abstract classes and methods, and features “pseudo-private variables” where a class can reserve internal method/field names that cannot be overridden by subclasses. The framework includes utilities for managing events and listeners, and can register event
handlers on object instances.
New Back-End / Rendering APIs
The “back-end,” which is responsible for rendering components within the web browser, has been re-engineered for Echo3. Instead of each component having its own client-server serialization code, Echo3’s web application container simply serializes the state of updated components directly to the client, where JavaScript versions of the server-side components are then created and updated. This feature makes the component development process substantially easier and faster than it was in Echo2. The new approach also yields performance dividends when creating server-side Java applications — Echo3 consumes less CPU and a mere fraction of the bandwidth of Echo2.
New and Improved Components
Many new components have been added to the framework and existing components have been enhanced in Echo3. WindowPanes, for example, will always stay on screen, even if the browser window or containing component is resized. Menus can be configured with opacity and fade-in effects. New components have been added to the Extras library including a RichTextArea and Tree/TableTree. New APIs for keyboard accessibility and focus management allow for mouse-less operation (note: still under development in some components).
The new Layout Manager allows you to create multi-pane user interfaces that are collapsible and resizable.
The Flash-enhanced File Uploader control might be known to you from Flickr and and allows you to easily batch-upload files and images with progress bars.
The JavaScript Profiler now has a graphical front-end to make the information more easily understandable
The YUI Data Table performs faster and got new features, including horizontal and vertical scrolling, a paginator class, drag and drop columns and an API to access, add and remove columns.
The Image Cropper control allows you to pick a part of an image to be cropped server-side
The Cookie Controller provides a wrapper for all things to do with cookies
The Slider Control got updated to support multiple handles to define a range rather than just a state.
In addition to that, some of the components left beta status. These are the Get Utility to retrieve scripts and style sheets on the fly, the ColorPicker Control, the JSON Utility to validate JSON, the ImageLoader Utility to load images on-demand to increase page performance and the YUI Test Utility.
I had the opportunity to sit down with three fine gents from Aptana to discuss their recent launch of Jaxer, the "server side Ajax framework".
Paul Colton, Uri Sarid, and Kevin Hakman all sat with me to chat about things. I have already played with Jaxer, and created the Google Gears wrapper which can be used seemlessly for use cases such as "If the user doesn't have Gears installed, just do it on the server".
We discussed a lot in the twenty odd minutes including:
Where the idea for Jaxer came from
The difference between a server side JavaScript framework and Jaxer (since there are many of them!)
How Jaxer works (think of a headless Mozilla browser)
Side effects of going this direction
How developers are using it
How does your architecture change if you are using Jaxer?
How can you talk to code in Java and other languages?
How JavaScript 2 fits into the picture
What about deployment?
A lot of good stuff. Thanks to the crew for taking the time to chat with me. What other questions do you have for them?
Marcello Bastéa-Forte has developed OnionML, a layout template language that uses server side JavaScript with Rhino and E4X on the back end.
The high-level goal of the template engine is to be something with utility not unlike CSS, but for intended layout and composition. The actual functionality is similar to XSLT, but with the design goal of being simple and easily extensible.
Onion ML is an XML template system designed with a bias toward modularity.
Onion ML lets you easily custom XML tags to make modular content design simple and easy to mix with HTML. It is somewhat comparable to XSLT and JSF, but intended to be easier to understand.
You define custom tags either as markup in XML files or as custom JavaScript functions which generate output.
Onion ML also provides several control flow methods necessary for dynamic content. Methods for iterating over data sets and conditionally displaying tags are core to Onion ML's functionality.
You end up building nested tag layouts. For example, you first define a tag:
Last week we posted about Jaxer which offers an approach of turtles all the way down where JavaScript is used on the client and the server.
Then, I got to interview Steve Yegge. Last year, Steve posted about Rhino on Rails, his port of Ruby on Rails to the JavaScript language on the Rhino runtime.
What can't you do since JavaScript doesn't have the same meta programming facilities?
Rails = a group of Active*, so did you re-implement everything?
What do you gain out of having JavaScript all the way down?
Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
What is the state of Rhino?
Will Rhino support JavaScript 2?
And of course, the big questions:
When do I get to see it!
I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.
This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.
Anyway, give it a watch and let me know what you think:
John Le Drew has been working on a PHP framework for a few years, and has now packaged it as Simplicity:
The Simplicity PHP Application Framework is an advanced, scalable and extensible PHP application framework to aid developers in creating high traffic, high availability Web 2.0 online applications. Integrating a solid MVC framework with some of the best Open Source projects around Simplicity aims to assist developers with any amount of experience in taking their applications to a new level.
One important piece is the Ajax admin console, developed in Ext that allows a developer will be able to configure all aspects of their application via the Ajax interface, this includes database modeling and the creation of stub controllers, and even the addition of predefined actions to speed up development.
I've long been a proponent of server-side Ajax frameworks -- frameworks that store state on the server and use an Ajax engine in the browser to drive the display. The advantages: state and control logic stay on the server, so security compromises that exploit client-side state and logic are more difficult to pull off; developers can work in one language and, for the most part, ignore the fact they are writing a web application. The disadvantages: the server retains a large amount of state, so scaling your application can be problematic.
There's one other large disadvantage to these open source server-side frameworks: for every 100 Java developers who use the framework, there is only 1 of them that can do serious JavaScript development. That means that the lifeblood of these frameworks -- the development of new and cool JavaScript widgets -- is sluggish at best. That has certainly been the case with the best known 3 frameworks: Echo2, ZK and ThinWire (though ZK does wrap a number of Ajax widget libraries, such as Dojo).
Back when GWT was introduced, it struck me that this would be the perfect way to write the client-side engine, to let the other 99 Java developers join in. I had the good fortune of being seated next to Joonas Lehtinen, IT Mill's CEO, at the GWT Conference in SF this past week and was blown away when he demo'd IT Mill Toolkit 5, his server-side Ajax framework (dual Apache 2.0 and commercial licenses) that, yep you guessed it, uses GWT for its client-side engine.
One important thing to consider is that IT Mill has extended the default GWT widgets so that they can be fully "rebranded" with CSS. They do provide an extensive reference manual that will guide you through developing your own custom components and integrating them with the server side.
I'd like to see the other server-side frameworks follow IT Mill's lead in using GWT for the client side, but given the amount of effort that they have put into building their client-side engines, that may be a ways off.
With so many good JavaScript frameworks available, it's getting harder to decide in which direction to head. Brian Reindel offers some good advice to those looking to embrace a framework but aren't quite sure what to look for.
A JavaScript framework may not make you a better programmer, but it will make you more efficient. That alone should be reason enough to choose a JavaScript framework, or library if you prefer. Unless you decide to build your own, there are plenty of options available to developers. However, choosing the right framework can be tricky, and weeding through a mess of opinionated fanboys (myself included) is intimidating.
Brian targets such areas as browser support, project maturity, documentation, & community and how they can have a profound effect on your choice(s). While a lot of the material will be repetitive to many experienced developers, it's definitely useful to those that are just now looking at leveraging a framework.
My colleague Brian Dillard is just putting the finishing touches on the 0.6 beta release of Really Simple History (RSH). What's new and improved?
I've tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I've didn't quite get there, but I got close.
Features in the new version include:
Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
Full support for Safari 2/Mac (though I'm still trying to eliminate the "infinite loading" bug before I push out the beta).
Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.
As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.
What was the main source of difficulty in this release? In a word, Safari.
Plenty of people who've worked on Ajax bookmarking projects have
commented about this, but it only becomes clear once you've actually
seen it in action. Getting this thing to work in Safari 2 for the Mac
took a wildly disproportionate amount of time considering its market
share.
Hopefully these dusty corners of the browser world will get improved over time.
, Component
