DuckDuckGo is a search engine that uses YUI extensively. Here’s what it uses in particular:

• ImageLoader. Matt Mlinac’s YUI 2 ImageLoader was the first thing I implemented and what originally hooked me on YUI for this project. DuckDuckGo has favicons next to results and often has “Zero-click Info” above results that usually includes an image. I didn’t want these images to compete with the results when loading, as getting results as fast as possible is the ultimate goal.

  The ImageLoader Utility handles this well by loading the images after the page load. DDG also auto-loads the next page of results when you scroll down. Sometimes the favicons icons are therefore hidden, and with ImageLoader their load is delayed (sometimes indefinitely) until necessary. To accomplish this, there is a different image group per (internal) page, each with its own custom trigger.

  div.event=new YAHOO.util.CustomEvent('it');
      var ig1=new YAHOO.util.ImageLoader.group(div,'click');
      ig1.addCustomTrigger(div.event);
      div.ig = ig1;
  

• Cookie. DuckDuckGo has a lot of settings, which are stored via cookies and alternately via URL params. When cookies are used, I use Nicholas Zakas’s YUI 2 Cookie Utility to easily get and set the values.

    YAHOO.util.Cookie.set(cookie, value, { expires: new Date("January 12, 2025") });
    x=ki||YAHOO.util.Cookie.get("i");

• StyleSheet. Some DDG settings change the look and feel of the site. These changes are actually accomplished after page load via Luke Smith’s YUI 2 StyleSheet Utility. Some of these changes are straightforward and I can just use the setStyle Dom function.

  YAHOO.util.Dom.setStyle('b2','display','block');

  Others require actual class changes, which I use the utility to do.

  YAHOO.util.StyleSheet('DDG').set('.ci', {display: "block"}).
              set('.cid', {display: "block"}).
              set('.ci2', {display: "block"}).
              enable();

• Dom. I also use some functions in Matt Sweeney’s base YUI 2 Dom component. I referenced setStyle above, and I also use the related getStyle, addClass and removeClass functions. In addition, I find the getViewportHeight, getViewportWidth, getX and getY functions to be incredibly useful to make things work cross-browser, and now on mobile screens as well.

• KeyListener. DDG has a bunch of keyboard shortcuts that let you navigate results without the mouse. I use the YUI 2 KeyListener component to enable these shortcuts.

  kl14 = new YAHOO.util.KeyListener(document, { keys:[70] }, { fn:not } );kl14.enable();

• AutoComplete. I’m currently working on adding search suggestions to the search engine, and will be using Jenny Donnelly’s YUI 2 AutoComplete component for the front-end. I understand that AutoComplete is getting introduced in YUI 3 soon. Everything else I use has already been introduced in YUI 3, though I still use YUI 2. However, I will be exploring the migration to YUI 3 soon.

About the author: Gabriel Weinberg is the founder of the DuckDuckGo search engine, based out of Valley Forge, PA. Gabriel has been a startup founder for over ten years, and his last company was sold in 2006. Gabriel holds degrees from MIT in Physics and the Technology and Policy Program.

Fast and fun – that was the user requirement for the new Assembla.com Agile Planner – an AJAX interface for adding development tasks, building story/feature outlines, and scheduling them into releases. We were lucky to have YUI 3 to make it fast and fun to implement as well.

I had used YUI 2 for a number of prior projects and I had been impressed by the engineering of the UI components and the underlying library infrastructure. I wanted to learn more about YUI 3, with its compact syntax and deeper focus on DOM manipulation and CSS3-style selectors. This project, with a low dependence on ‘prebuilt widgets,’ was a perfect opportunity to get my feet wet with YUI 3. The facilities for ‘large app’ implementation via custom modules and integration with YUI loader made it a natural choice.

The Agile Planner supports a number of drag and drop user interactions with multiple interaction groups and context based behaviors. At the same time, it handles a complex set of interactions with the server, including merging in new data from the server, and propagating changes to the server.

We improved on the existing Planner which was based on Rails handlers and Prototype.js. YUI’s sandbox philosophy and strong OOP facilities made coexisting with Prototype.js a breeze.

We used a large number of YUI components, including:

• Async-Queue to offer a responsive experience on a page that can involve 1000+ simultaneous tickets
• Drag and Drop with interaction groups.
• IO as a connection manager to queue and massage server interaction.
• Event-delegate to allow simply hydrating html templates and forgetting about them.
• Event-key for keyboard interaction and navigation.
• Collection for giving us a consistent implementation experience across browsers.
• Cookie for easy short-term UI persistence.
• Profiler to find the biggest speed gains
• YUI Doc to leave information for the rest of the team

Working with YUI 3 on an app like this has been fun, and I am looking forward to hearing what our users will urge us to do next!

About the author: Joachim Larsen is a frontend engineer with Assembla.com.

Tell us a little about your project.

“Demeter” is the codename for a recent web 2.0 application we built which provides powerful solutions to web conferencing, ad hoc meeting, and account management. Currently we have two major product suites: “Meeting Center” and “Admin Module”.

Although it’s still in RC phrase with no public access to view it, I have extracted a prototype of the Admin Module that demonstrates the management of portal properties.

Which components of the YUI Library are used in your project?

When we were initially trying to decide which JS framework and UI library to use, there were three things that sold us on YUI: the great documentation, the wide variety of mature widgets, and the BSD license, so I introduced YUI to my company. The following modules are used in our project:

• CSS: Reset, Fonts
• Core: YAHOO, Dom, Event
• Utilities: Connection Manager, DataSource, Element, JSON
• Widgets: Calendar, Container, DataTable
• Tools: Logger, Test

Admin module implementation overview

Our main requirements for the Admin module included:

• datatable with a customized editor popup
• theme/skin customization
• browser compatibility

Here is the simple markup that sets up the UI:

    <div id="datatable-ux">
		<div id="datatable-ux-hd"></div>

		<div id="datatable-ux-bd">
			<div id="node-depths" style="display: none">root  > Testing  > 5_Dev Testing BA  > 80000_1010</div>

			<div id="output"></div>
			<div id="yui-datatable" class="yui-dt">
			  <img src="images/icon-loading.gif" alt="loading" align="absmiddle" style="margin: 30px 0;" /> loading data...
			</div>
		</div>

		<div id="datatable-ux-ft"></div>
    </div>

	<div id="node-apply-wrap" style="display: none;">
		<fieldset>
			<legend>Apply to</legend>

			<input type="radio" name="node-apply" checked="checked" />Current node only<br />
			<input type="radio" name="node-apply" />Current node and child nodes<br />
			<input type="radio" name="node-apply" />Child nodes only
		</fieldset>
	</div>

Here is a code snippet of the simple extension I built for DataTable TextboxCellEditor:

   // simple example to extend the CellEditor Classes
   // short alias
   var lang = YAHOO.lang,
	  util = YAHOO.util,
	  widget = YAHOO.widget,
	  Dom = util.Dom,
	  Event = util.Event;

   // extend TextboxCellEditor
   Gcc.admin.TextboxCellEditor = function(config) {
	   Gcc.admin.TextboxCellEditor.superclass.constructor.call(this, config);
   };
   lang.extend(Gcc.admin.TextboxCellEditor, widget.TextboxCellEditor, {
	   renderForm : function() {
		   Gcc.admin.TextboxCellEditor.superclass.renderForm.call(this);

		   var oHd = document.createElement('DIV');
		   this.getContainerEl().insertBefore(oHd, this.textbox);
		   oHd.id = container.id + '-admin-editor-head';
		   Dom.addClass(oHd, 'admin-editor-hd');

		   var oCurrNode = document.createElement('DIV');
		   this.getContainerEl().insertBefore(oCurrNode, this.textbox);
		   oCurrNode.innerHTML = 'Current node: ' + Dom.get('node-depths').innerHTML;
		   Dom.addClass(oCurrNode, 'admin-editor-pd');

		   var oApply = document.createElement('DIV');
		   this.getContainerEl().appendChild(oApply);
		   oApply.innerHTML = Dom.get('node-apply-wrap').innerHTML;
		   Dom.addClass(oApply, 'admin-editor-fieldset');
	   },

	   move : function() {
		   Gcc.admin.TextboxCellEditor.superclass.move.call(this);
		   Dom.addClass(this.textbox, 'admin-editor-pd');
	   }
   });

Then a cellClickEvent handler detects the underlying type of data value being edited and calls one of the customized cell editors.

With our server architecture consisting of the Apache Struts framework and the application container Weblogic, we found that YUI plays a good companion role as the “Clientside-Controller” and works well with Struts action results as a dynamic datasource.

<%@ page pageEncoding="UTF-8" contentType="application/json; charset=UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
{"PropertySet":{
"Property":[
<s:iterator value="displayPropertyResultList" status="index">;
    {
    "Id":"<s:property value="id" />",
    "Name":"<s:property value="name" />",
    "Type":"<s:property value="type" />",
    "Value":"<s:if test="%{value != null}"><s:property value="value" /></s:if>",
    "ApplyFrom":"<s:property value="applyFrom" />",
    "ApplyTo":"<s:property value="applyTo" />",
    "Readable":"<s:property value="readable" />",
    "Writable":"<s:property value="writable" />"
    }
    <s:if test="%{!#index.last}">,</s:if>

</s:iterator>
]}
}

More details and source code are available on GitHub, where I have extracted a prototype of the Admin UI using a local datasource as a simple demonstration.

What have been the challenges of using YUI in this project?

The main challenges have been around the fact that most of our developers are in fact not frontend engineers. They don’t always have quite as much experience dealing with cross-browser issues or JavaScript-specific tricks. Fortunately YUI helps us a lot to make good code structures and to smooth out most browser compatibility issues.

What’s next for Demeter? What are some upcoming features you are tackling with YUI?

One of the upcoming features we are working on is a reporting module that will make heavy use of YUI Charts. And we are also planning to use TreeView widget to refactor our addressbook module.

We are still using YUI 2, but if more and more official widgets based on YUI 3 come out, we will consider totally moving to YUI 3 in the future.

Cory Mintz from Phanfare wrote in last week to tell us about their recent product launch, which is heavily based on YUI 2.8.0.

We just released our new web organizer yesterday… It is a full photo and video organizer built as a web application, using just about every YUI 2 component. We think it really blurs the line between desktop and web software.

Some notable features are:

• Using the Uploader, we let people organize and edit their photos as they upload.
• With the help of Drag and Drop and Menu, the thumbnail grid has all of the behaviors of an OS’s file browser. You can drag select, drag and drop reorder, multi-select using ctrl and shift, arrow between thumbnails, etc.
• The dynamic loading of the TreeView, let us lazy load user accounts with 100s of albums since they are hierarchical ( year -> album -> section ). This allows the page for an extremely large account to load just as fast as a small account.

I love the clean professionalism of the site and the extraordinary attention to detail in the UI. Feel free to tour the site — trial accounts are free and come populated with sample albums to give you a feel for what the site has to offer. Congratulations to Cory and the team for such a fantastic launch.

Tell us a little about your project.

I had been putting off a website for my uncle’s company for some time, but with the help of YUI, I built his entire site from scratch in just 3 days.

What is your background with YUI? Why did you choose YUI for this project?

I have been using YUI for the past 2 years. In my previous job, I introduced it into every single internal application. I chose YUI for this project due to my familiarity with it, and because it does ALL of the hard work for you. In short, YUI makes me look very good on a daily basis.

Which YUI components in particular are in use?

I used the Carousel, AutoComplete and my absolute favorite, the DataTable.

What have been the challenges of using YUI in this project?

The main challenges were with a couple of Carousel bugs. These were issues I did expect, as it is still in beta. The only really major issue I had was figuring out why 2 carousels on the same page didn’t play nicely together. Then I realized that their items shared the same IDs.

What are the things you’re most proud of in this project?

I am proud of the fact that I was able to provide a rich user experience very quickly. Specifically, the catalog page that uses the AutoComplete widget with the DataTable allows users to easily browse a movie catalogue of over 4000 movies and games.

What are some upcoming features/projects you are tackling with YUI?

Next order of business, finish the Form Validation component I have been working on with Luke Smith for YUI 2. I am excited to see how it’s received by the YUI community. I also plan on introducing YUI to companies I will be working with in the near future.

How did the YUI components perform?

They performed excellent. The DataTable was able to handle 4000 records at a time without an issue. I have found that the performance of the YUI components has steadily improved with every release.

About the author:Matt Berg is a co-founder of Vitalist, the premier web-based productivity manager for GTD. Matt is responsible for the UI and usability of the various Vitalist applications. He has a B.B.A. in MIS from the University of Texas at Austin and has been working on web applications since 2000. You can follow Matt on Twitter at @mattberg

About Vitalist

Vitalist is a powerful personal organization tool that closely follows the popular Getting Things Done methodology by David Allen. With Vitalist, all of your to-dos are online, in GTD format, and ready to be accessed or updated from anywhere.

Why YUI?

We have been using YUI at Vitalist pretty heavily since around version 2.2.0 — for about three years. Initially we ended up choosing YUI out of the available JavaScript frameworks for two major reasons: documentation and code footprint. To this day, I feel YUI continues to lead the pack in both of those areas.

With user interfaces getting more complex everyday, another major benefit of YUI is the number of available utilities and widgets. And at Vitalist we are taking full advantage, using the following components (version 2.8.0r4): animation, autocomplete, browser history, calendar, compressor, connection, cookie, CSS fonts, CSS reset, datasource, dom, drag and drop, element, event, json, logger, menu, selector, swf, tooltip, yahoo.

Obsession with Performance and Responsiveness

Early on at Vitalist we decided to go the rout of loading most of the necessary components and data on the initial visit to our main application. This was done for two reasons, UI responsiveness and ease of offline setup. Let’s focus on responsiveness.

While in theory it’s simple, having JavaScript handle basically all of our UI generation definitely added some complexities. For example, the speed of appending and traversing the DOM is of the utmost importance. Something as simple as adding a root element to the getElementsByClassName function boosts performance significantly. And sometimes we had to sacrifice programmatic convenience for speed. While the YUI 2 Selector Utility can be very powerful, we originally found getElementsByClassName to be faster. (With the latest releases of YUI 2, the Selector Utility performance seems to have increased quite a bit, but we still default to getElementsByClassName when possible to boost performance — especially in browsers that have native support, which YUI 2’s Dom Utility leverages.)

YUI 2 AutoComplete powers one of the newer features of Vitalist, released in the last year or so, but it has also been one of the hardest implementations in terms of responsiveness and browser CPU usage. In our initial attempt, every time we needed a new autocomplete control for an input we would create a new instance, destroying it once it was no longer needed. This typically happens when moving from “page” to “page” (keep in mind, all of our “pages” are just client-generated screens). Internet Explorer struggled with this, often pegging the CPU at 100% and effectively bringing the computer to a halt. This forced us to turn off autocomplete support for IE. Two key changes helped us create a more efficient autocomplete. First, we create just a few generic instances of the autocomplete that can be shared from “page” to “page”. Then the only update necessary is setting a new DataSource, which in our implementation requires less CPU effort. Number two, pay attention to the maxResultsDisplayed property. Because we allow the full autocomplete list to be displayed without any input (we also added the down arrow key to show the list), we initially set the maxResultsDisplayed to an arbitrarily large number like 10,000. Simply changing this number to the length of our actual datasource resulted in significant CPU performance gains.

For monitoring performance on the front-end, we use the YUI 2 Logger Control. When in debug mode, we output many log updates detailing the various steps of JavaScript processing. One great thing about the logger is the fact that it keeps a timestamp of when it was last updated. This has been very helpful when trying to figure out the bottlenecks in our code. And for more of the server side performance monitoring, YSlow has also been very helpful in making sure we are generating http requests as fast as possible.

Most Interesting Implementation Feature

Personally, I had the most fun implementing drag and drop in Vitalist (using YUI 2 Drag and Drop). Drag and drop actually serves two purposes in Vitalist for the same drag element. First, we use it for manually re-sorting lists; secondly, we use it for moving tasks between lists. To accomplish this, two different drop target “zones” are used: one for the list elements in the content and one for the list elements in the left sidebar menu.

The interesting part here is the two different zones function quite differently. When dragging in the content area, we want the drag element to constantly move the hovered element and append the drag element in the new location. In the menu area, we don’t want to anything to shift, but we do want to highlight the menu selection we are hovering over. Here is a code snippet from the onDragOver method:

if (destElNodeName === "li") {
	orig_p = srcEl.parentNode;
	p = destEl.parentNode;

	if (!_D.hasClass(p.parentNode, "nav")) {
		if (this.goingUp) {
			p.insertBefore(srcEl, destEl);
		} else {
			p.insertBefore(srcEl, destEl.nextSibling);
		}
	} else {
		_D.removeClass(_S.query("#sidebar .nav:not(.alt) li"), "drag");
		_D.addClass(destEl, "drag");
	}

	_DDM.refreshCache();
}

Building Vitalist components with YUI Compressor

Related to our obsession with performance, we created a web front-end that uses the YUI Compressor in conjunction with some other scripts to build the various JavaScript and CSS components used throughout Vitalist. This ensures we are keeping the smallest code footprint possible for each of the major sections of our site. And as you may know, keeping the number of http requests as low as possible helps on page load times, so combining JavaScript and CSS files where possible can help a great deal.

Some background is necessary here. Vitalist has its own core set of JavaScript utilities and CSS that are shared across all of the major sections of the site. Each individual section (such as the main application, iPhone-optimized application, or marketing site) has its own specific JavaScript and CSS.

So the basics of the build process are as follows: First, the global JavaScript and CSS files are minified using YUI Compressor. Then, for each section, the various JavaScript and CSS files are minified, and then combined with the global file to create one single file. In addition, each section only requires certain components of YUI, so each of the required pieces are combined into a single YUI file, further reducing the number of files needed.

What’s Next?

The next major project with Vitalist using YUI will be upgrading to the YUI 3 framework. With version 3.1.0’s ability to use legacy YUI 2 components easily, it’s time to make the move.

If you are interested in learning more about Vitalist, please check out our website: www.vitalist.com. Also, feel free to email us at support@vitalist.com with any questions you may have.

EtreProprio.com aims to provide high quality classifieds for free (see an example of a listing here). There are currently more than five thousand property owners selling their houses on EtreProprio.com. We wanted to provide a simple but powerful interface, and we needed a lot of front-end logic. After a little experimentation, we chose YUI which struck us as powerful, robust, very well documented and highly customizable. As a consequence, EtreProprio.com is using YUI (2.8.0) heavily for its front-end.

The following modules are used:

• CSS: Reset, Base
• Utilities: Animation, Connection Manager, Cookie, Datasource, Drag and Drop, JSON
• Widgets: AutoComplete, Button, Calendar, Container, DataTable, RTE, Slider, TabView, Uploader

Let’s go deeper on three implementations: Advanced Search, Photo Uploader and TabView.

Advanced Search

The form used to find properties is developed on top of AutoComplete and Dual Slider. The labels above slider thumbs are positioned by listening to change event. Then, they are repositioned if a collision occurs between min and max labels. The AutoComplete implementation can display mixed elements such as cities, postal codes or regions. Each element has its own display format.

Try it live.

Photo Uploader + Management

We used YUI’s Uploader, DataTable and Drag and Drop modules in order to create simple form for photo uploading. First, the user selects the photos on his computer. Then he clicks “Send all” and as the photos are sent, a table below is populated with the photos and details. Drag and drop is applied to the rows of the table, it allowing users to easily reorder the photos. The description of each photo can be modified using a simple text input and YUI’s XMLHttpRequest utility, Connection Manager.

See the video below for a demonstration:

TabView

As there is a lot of information to display in a classified detail, we used TabView to design the page. The CSS personalization capabilities of TabView allow us to integrate it perfectly with the rest of the page from a design perspective. Tabview also saves us bandwidth as only interested users click on all the tabs — TabView has support for lazyloading Tab content, and that pattern works well for us here.

Fybit Riatrax4Js: Write YUI in Java

YUI is not only a fantastic JavaScript library, it is also a great community. Developers
contribute to YUI and allow others to benefit from it. Now,
Fybit joins the YUI community with
Riatrax4Js, a
toolkit for rich internet applications (RIAs) based on YUI.
Riatrax4Js allows you to program RIAs in plain Java and automatically translates your code
to JavaScript, using YUI as a foundation layer. With YUI being available
from Python, Java and JavaScript,
one fourth of all developers get access to YUI.
And with 18%,
Fybit’s Riatrax4Js covers the largest part, consisting of Java developers.

Riatrax4Js: Java benefits, powerful YUI widgets

We just launched the Riatrax4Js alpha version with the goal of easing
development of YUI-based RIAs. Riatrax4Js combines the advantages of Java
with the extensive widget set and controls of YUI. Consequently, you get the
benefits and comfort of Java programming such as:

• Type safety
• Inheritance
• IDE support (Eclipse, NetBeans, …)
• Debugging
• Test tools like JUnit
• Access to many 3rd party libraries

And you all know how fantastic YUI is:

• Many powerful widgets
• Compatible with all major browsers
• Great performance
• Yahoo! experts develop YUI

Add up the advantages of Java and YUI, you get the properties of
Riatrax4Js. Riatrax4Js is not a server-side framework. It compiles Java
to JavaScript, leveraging the standard Java compiler to give you unlimited
scalability and speed. Moreover, Riatrax4Js allows you to connect
your YUI frontend to the web server and backend with a simple annotation-based
remoting mechanism.

A simple example: Show the server’s time on a button’s label when clicked

This section walks you through a simple example that is available for
download from our website.
Riatrax4Js apps consist of regular Java classes that can use the Java version
of YUI that ships with Riatrax4Js. Here is how simple that is:

@MainPanel(name="index")
public class DemoPanel {

	@Services(implementation=TimeServiceImpl.class)
	protected static TimeService service;

	public DemoPanel () {
		final Button syncButton = Button.create("syncButton");
		syncButton.addClickListener(new Listener() {
			public void perform () {
				syncButton.setConfLabel("Sync: " + service.getTime());
			}
		});
	}
}
		

The code starts with a @MainPanel annotation to allow Riatrax4Js to
find the entry point to your program. Next, there is a field service
that is annotated with the @Services annotation. Thanks to this annotation,
the server can be called to get the time (or any other value/object you
want to use on the client). It does not have to be explicitly initialized,
Riatrax4Js does the dirty work for you and ensures that the client and server
parts are connected by injecting an appropriate proxy. A YUI Button is then
created by replacing an existing HTML button “syncButton” of your HTML page. A click listener
which invokes the time service on the server is attached to the button. This
is a synchronous (i.e., blocking) call. Async calls are just as easy:
The generated proxies contains an async variant
of each method in the interface that can be readily used. Here is the corresponding
HTML page for the code:

<html>
	<head>
		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<title>Fybit New</title>
		<script type="text/javascript" src="codebase/app-index.js"></script>
	</head>

	<body class="yui-skin-sam">
		<button id="syncButton">Synchronous Call</button>
	</body>
</html>
		

The most important line is the script tag at the beginning. It includes a
single JavaScript file app-index.js where “index” is the name given in the
@MainPanel annotation above. In the HTML body, you can find
the aforementioned HTML button. Riatrax4Js wraps the YUI Button over this button.

When you compile the application, Riatrax4Js analyses the source files and generates the file app-index.js
consisting of the Java classes needed in the browser translated to JavaScript
as well as the necessary YUI JavaScript code. Unlike with native YUI, you don’t
have to care about YUI dependencies or which YUI files to include — Riatrax4Js
includes them automatically!

This is just a small excerpt from a larger demo.
The full demo also explains how to call the server asynchronously and how to use other
YUI widgets (text editors, auto-completion, menus etc.). Apart from generating web
application from scratch, using Riatrax4Js you can improve existing web applications
easily with interactive features by wrapping ordinary HTML elements with YUI elements.

Beyond demos: “PublicationManager” written with Riatrax4Js

We used Riatrax4Js to develop a user-friendly web application to
manage publications for a research group at a university in Switzerland.
This application facilitates the process of entering and modifying publication
records and it has been put into operation in November 2009. The
PublicationManager features YUI
dialogs, sortable and resizable tables, paginators and auto-completion. The records
entered by the users are stored in a database and can be edited and complemented with
files with just a few clicks.

Security

Riatrax4Js is designed to make applications as secure as possible by default.
But because Riatrax4Js uses JavaScript, applications are as hard to secure as
any other dynamic web app. Fybit offers separate extension to Riatrax4Js,
Riatrax Security.
It is based on Riatrax4Js’s
program code analysis and secures the application by filtering invalid or
malicious content and blocking it before it reaches your code and/or application server.
Fybit Riatrax Security is also configured with Java annotations.

Want to try?

The alpha version of Riatrax4Js is currently available on our web site to registered users.
It’s great to see the user base of Riatrax4Js grow and be used by developers at this stage.

Fybit’s goal is to make Riatrax4Js the best Java RIA toolkit available and support
it in the long run. We believe that the YUI community and YUI developers can
give us important feedback about Riatrax4Js. We are excited to hear your questions
and suggestions, e.g.

• How can we improve Riatrax4Js?
• For what kind of projects would you consider Riatrax4Js?
• What is the best way for us to distribute the product?

As Fybit is a small startup company, we appreciate everyone who wants to
contribute to Riatrax4Js to make it the number one RIA framework. Just
drop us a line if
you are interested or want to know more.

Enterprise Web Developer (EWD), a Python/YUI framework

Since the early days in 1996, I wanted people to be able to use web technologies as a user interface to applications that they’d previously have considered using Client/Server or some other GUI technology to create. It seemed to be to be a technology that had the potential to be heavily automated so that developers could focus on expressing what they wanted to do rather than how to achieve it.

The thing that has always dismayed and surprised me is how the industry has not embraced this philosophy. Whilst there is no shortage of web/Ajax frameworks out there – there seems to be a new one every week – they all have a common theme: the notion that a web/Ajax application is primarily a programming issue. By contrast I’ve been firmly of the view that by building a framework that was first and foremost design-focused, the programming aspects could be potentially automated to such a degree that the actual programming required in even a complex healthcare application should be able to be reduced to almost trivial levels. That’s been the design goal of our EWD and it proves that such an approach is practical, feasible and highly beneficial.

Why Python and YUI?

We’ve ported EWD to the free Open Source NoSQL database GT.M and Chris Munt, M/Gateway co-founder, has developed a number of language bindings that EWD can use. Our recent slidecast series (described below) was based around his Python binding because it’s such a popular language these days – recent reports suggest that it has grown in use by 45% since April 2008. However, you could use EWD just as easily with Ruby or Java.

Our screencast series focuses on EWD/YUI integration for several reasons:

• YUI provides a very powerful and highly functional and usable set of UI widgets
• unlike many of the Javascript frameworks, YUI is not an “all or nothing” environment, so you can mix and match YUI components with your own
• YUI is a free Open Source library so in combination with EWD and GT.M running on a Linux platform, the demo is based on a completely free Open Source stack
• it has the Yahoo! and Douglas Crockford pedigree: what more need you say!

EWD uses XML syntax to incorporate YUI. What advantages does this offer?

Making EWD work with YUI was pretty straightforward, but it soon became clear to me that the average developer faced quite a few obstacles when adopting such a Javascript framework for their UI development. Frameworks are complex environments, requiring a lot of detailed knowledge of pretty advanced Javacript, there’s a big learning curve and there’s a lot of “devil in the detail”. Furthermore, that complex and verbose Javascript requires downstream maintenance, often by someone other than the original developer. Additionally, for me, they presented yet another example of how the industry’s solution to web/Ajax application development was moving further towards programming and away from the skillsets of designers.

From the earliest days of EWD I’d ensured that it was user-extensible, allowing you to encapsulate functionality and behaviour as XML-based “custom tags”, and they proved to be a perfect solution to incorporating YUI. The YUI custom tags I’ve demonstrated are therefore a custom extension of EWD. The YUI custom tags not only generate all the Javascript needed by the corresponding widget, they also manage the destruction of the widget at the correct time, and include optimised “just in time” loading of the correct .js and .css files, leaving the developer to not have to worry about all that up-front configuration stuff. Another key feature of XML tags is that they are inherently nestable, and usually that’s exactly what you need to do with YUI widgets: menus and datatables nested inside tab-panels for example. So the real advantages are that the developer can express what he/she wants to do in just a few intuitively named and laid out custom tags. Not only does it make development quick and simple, but downstream maintenance also becomes simple too (and remember that one of the major costs and overheads of a big, mission-critical application is maintenance).

A good example is the use of TabView widgets. In EWD these can be described by a simple, intuitive (and therefore highly maintainable) set of nested XML Custom tags, eg:

<yui:TabView>
    <yui:Tab label="By Artist" active="true" dataSrc="selectCDXArtist.ewd" />
    <yui:Tab label="By Title" active="false" dataSrc="selectCDXTitle.ewd" />
</yui:TabView>

The yui:TabView Custom Tag’s tag processor is invoked by EWD’s compiler when it encounters an instance of this tag, and it generates the run-time code that will send the appropriate YUI TabView Javascript and associated HTML markup to the browser.

EWD instructional series

We’ve done a series of screencasts to introduce EWD. Here is Part One:

The goal of the screencasts was to demonstrate the extreme level of automation of EWD when used to its full potential. I also wanted to demonstrate how, in EWD, you’re very much describing what you’re wanting to achieve, leaving EWD to do all the how work and to handle all the day-to-day things that are essential to a web application but that can and should be automated, eg session management, security management etc. I hope when people watch the videos they see how little programming has been left for a programmer to do: it’s basically fetching data from the database, validating form fields against a database, and saving data back to a database.

They always say a picture is worth a thousand words, and I think a video is even more potent. Seeing is believing, and there’s nothing like being shown how a tool can be used by the guy who designed and wrote it!

I chose to explore a set of typical UI interactions for an average application that could be demonstrated in the space of about an hour. I also wanted to demonstrate how nesting of the UI components was possible using both the inherent nesting of YUI custom tags and EWD’s “fragment”-based Ajax architecture. The demo covers logging into an application, a main menu, tab panels for choosing the action required and a query against the database whose results are presented in a DataTable. Hopefully the fact that I’ve been able to demonstrate how all that functionality can be created in just over an hour shows the power and benefit of EWD as a development framework. And in terms of maintainability, the entire application I demonstrate is described in just 134 lines of simple HTML/XML markup and only 78 lines of straightforward Python code!

Where can people get EWD to try it out for themselves?

The quickest and simplest way to get a fully-working EWD system up and running is to use our free M/DB Installer. We’ve done a

screencast for this too.

At present the EWD/YUI Custom Tag library isn’t generally available, but we’re hoping to be able to release it soon.

We also have a forum for EWD users that people are very welcome to join.

Here at Edmunds (Edmunds.com) we just launched a redesign of
Inside Line (InsideLine.com), our automotive enthusiast web site, and we are using the YUI JavaScript library extensively.

Some of the YUI utilities & widgets used on Inside Line:

• Yahoo/Dom/Event
• Animation Utility
• Connection Manager
• ImageLoader
• JSON
• Selector
• Carousel
• TabView

We (the Frontend team) started out with YUI 2.7.0 JavaScript core and built our own JavaScript user interface library on top of it to encapsulate site-specific components and functionality. Our library takes advantage of YUI’s core utilities, including Dom, Event, Connection Manager, and Animation.

We are using Dom and Event extensively to handle DOM interaction, event listeners and custom event handling. The YUI Connection Manager is handling all of our Ajax implementations, including our custom search widgets. We are also using many of the YUI widgets on Inside Line, including TabView and Carousel, with custom skins. The YUI ImageLoader helped us improve page performance and meet our strict performance requirements.

We chose YUI because of its great documentation, thorough testing, and the scope and depth of its offerings. The library is easy to learn, understand, and implement. The modularity of the system fits in well with our design principles, and the API and custom events make it extremely extensible and easy to integrate.

Some Highlights

Multimedia Spotlight (tabview, carousel) from InsideLine.com:

Image and Video Galleries (core, JSON and Carousel):

Ajax Search Widgets (Dom, Event, Connection Manager):

Do you have a YUI Imlementation you’d like to share on YUIBlog? Check out our contribution guidelines — we’d love to hear from you.