Parisian coder Eric Abouaf (aka “Neyric”) released version 0.1.0 of his YUI-based forms library, inputEx.

As of this release, inputEx supports only client-side-generated views — form fields are configured in a JSON format and created for you on the fly. Eric identifies the following unique features in inputEx:

• complex data structures (list/objects/tree/list of urls/objects of objects etc…)
• composition between the fields (for “meta”-fields such as InPlaceEdit, List, Tree, Pair, …)
• javascript object mapping for greater interactivity
• a common “updated” event to handle different browsers and different field interactions

Eric has API docs, a Getting Started tutorial, examples, and more on the website. He’s looking for contributors, if you’re interested in extending the library; check out the website for full details on the project.

The training curriculum includes semantic HTML, CSS, JavaScript, DOM, YUI, PHP, accessibility, performance, and more. Juku trainees are full-time Yahoo employees, and upon completion of training they move on to roles within the Yahoo network as Front End Engineers. Last fall, we piloted the program with a group of 13 students and the results have been overwhelmingly positive.

We’re excited to announce that we currently have a few openings to join our next 10-week training session beginning in mid-June in Sunnyvale, California. If you’re a budding Front-End genius with a strong background in programming fundamentals and a passion to learn, we’d like to hear from you. But, the good news is you don’t have to work for Yahoo to benefit from Juku training: The lecture portions of the training will be videotaped for distribution via the Yahoo! Developer Network later this summer.

To apply for a spot in the next Juku training session, check the job posting. Applications must be received by May 15th.

Douglas and his editors at O’Reilly were kind enought to let us offer a sneak preview of JavaScript: The Good Parts here:

• Chapter 5: Inheritance — 1.2MB PDF

Here’s how Douglas opens the discussion of inheritance in JavaScript:

Inheritance is an important topic in most programming languages.

In the classical languages (such as Java), inheritance (or extends) provides two useful
services. First, it is a form of code reuse. If a new class is mostly similar to an existing
class, you only have to specify the differences. Patterns of code reuse are extremely
important because they have the potential to significantly reduce the cost of software
development. The other benefit of classical inheritance is that it includes the
specification of a system of types. This mostly frees the programmer from having to
write explicit casting operations, which is a very good thing because when casting,
the safety benefits of a type system are lost.

JavaScript, being a loosely typed language, never casts. The lineage of an object is
irrelevant. What matters about an object is what it can do, not what it is descended
from.

JavaScript provides a much richer set of code reuse patterns. It can ape the classical
pattern, but it also supports other patterns that are more expressive. The set of possible
inheritance patterns in JavaScript is vast. In this chapter, we’ll look at a few of the
most straightforward patterns. Much more complicated constructions are possible,
but it is usually best to keep it simple.

Click here to keep reading (1.2MB; PDF).

Thanks to Laurel Ackerman and Simon St. Laurent at O’Reilly for the permission to share the sample chapter.

One of the challenges faced in creating and deploying Rich Text Editors is the number of markup formats you may need to support on the output side — ranging from HTML to Wiki-style text to purely idiosyncratic markup styles. Dav worked hard on the YUI Rich Text Editor to make output transformations as straightforward as possible. (If you’re doing YUI RTE work and haven’t seen Dav’s video intro to the component, you can check it out here.)

Glen Smith from Canberra shared some antipodean YUI goodness today with a quick tutorial on using the YUI RTE for editing Wiki text. He’s been using the Grails YUI Plugin, mixing in a little textile-j, and he’s got something working well enough for version 1:

Turns out the recipe for making all this work is pretty straighforward:

• When switching from Wiki markup to HTML, do an Ajax call to a backend Grails controller that uses textile-j to convert from textile markup to html. Feed the result of the AJAX call to the YUI Rich Editor and you’re in business.
• To support switching from RichText to Textile, again do an Ajax call back to the Grails controller to the do the conversion. This time you’re on your own in regexp land, but you can trim the amount of work you’ve got to do by what you expose in the Rich editor. Return the results and inject into the Wiki textarea.
• To get the underlying html from the editor just use myEditor.getEditorHTML(). Awesome!

For more, check out Glen’s blog post and accompanying QuickTime movie.

Chad at 2tbsp.com wrote up a nice tutorial last week outlining some practical fundamentals with respect to writing "unobtrusive JavaScript." His example implements a standard rollover, beginning with bad-old-days obtrusive scripting, migrating to unobtrusive scripting, and concluding with an unobtrusive script that leverages YUI’s Event Utility for event attachment and the Dom Collection’s getElementsByClassName, addClass and removeClass for class management.

Click through for his functioning example.

Of course, Chad just means this as an example of some of the practical points involved in unobtrusive scripting. Others have looked at the problem more encyclopedically — for a more ambitious (and not YUI-related) analysis of the paradigm, check out Christian Heilmann’s "The seven rules of Unobtrusive JavaScript".

Over on DjangoSnippets.org, akaihola has posted a YUILoader class (based on Adam Moore’s client-side YUI Loader) that makes it a snap to pull YUI components into your Django projects.

This server-side middleware implements some of the functionality in the Yahoo User Interface Loader component. YUI JavaScript and CSS modules requirements can be declared anywhere in the base, inherited or included templates, and the resulting, optimized <script> and <link rel="stylesheet"> tags are inserted at the specified position of the resulting page.

Requirements may be specified in multiple locations. This is useful when zero or more components are included in the HTML head section, and inherited and/or included templates require possibly overlapping sets of YUI components in the body across inherited and included templates. All tags are collected in the head section, and duplicate tags are automatically eliminated.

The middleware understands component dependencies and ensures that resources are loaded in the right order. It knows about built-in rollup files that ship with YUI. By automatically using rolled-up files, the number of HTTP requests is reduced.

Back in August on DjangoSnippets, pigletto posted a nice YUI snippet for use with the YUI AutoComplete Control.

David Cilley this week published the second in his series of articles on using the YUI Slider Control to provide real-time previewing of image changes.

• Part 1: The OnDemand method.
• Part 2: The Interval method.

In this second installment, David takes on the challenge of making the preview feel instantaneous without computing or delivering every possible image represented by the slider’s continuum:

On the previous slider example, I used a YUI slider that had a range from -100 to 100. This is a total of 201 different combinations for one image dialog, and that’s about 10-20 times more requests than a web server should have to handle in a reasonable amount of time. We want to make this look as if the slider is actually changing the image while we scroll it, but we don’t want to request 201 images up front, and we don’t want to load them all on demand either.

A part 3 in the series, David notes, will continue to refine the control. [Update: David has posted Part 3.]

For more Slider Control examples, check out the YUI Slider example roster; and don’t miss Todd Kloots’s Slider/Button example, which would be another way of presenting the control David is describing in his article series.

Mitch at PlankDesign.com has posted a nice review of one of the least-discussed aspects of YUI Core — the YAHOO Global Object’s YAHOO.lang member. He covers a number of the language conveniences provided therein, including type checking, trim, substitute, later and merge.

Luke Smith from the YUI team recently added some great examples of other features in the YAHOO object, so check those out, too, if you’re interested in learning more about this essential building block of YUI.

Thanks for the insights, Mitch!

If you’re heading to Web 2.0 Expo this week, stop by the big Yahoo booth and say hello. Dav Glass will be at the booth tomorrow (Wednesday) and Jenny Han Donnelly will be joined by Adam Moore on Thursday along with our friends and colleauges from the Yahoo Developer Network. We’ll have YUI Cheat Sheet packets to give away and lots of other good YDN schwag; come by early and often! Dav, Adam and Jenny will obviously be there to answer any questions you might have about YUI, too, so bring those by if you want some one-on-one time with the team.

Caridy, a leading and always-helpful contributor to the YUI community forum, has been working in front of a PC since the nineties. For the past eight years he’s been a professional programmer developing LAMP applications for the University of Las Villas where he received his B.S. in Computer Science in 2003, and for several companies around the world. He left his university job in August to pursue an independent consulting career and to follow his passion for open source solutions and agile development.

For the last two years he’s been focused on JavaScript as a development platform. Early last year he decided to create an easy-to-adopt YUI extension called “Bubbling Library” as a side project; you can read his YUIBlog introduction to the Bubbling Library here.

Creating complex web applications demands organization and modularization. Modularization introduces a new problem — the comunication pipes between components. This is a serious challenge for developers, as more components and widgets mean more pipelines and more dependencies. In this article, we’ll look at a technique to mitigate these issues: Creating an abstraction layer to moderate the comunication between the components and widgets in a web application. This technique is based on YUI and makes use of my Bubbling Library, which is a BSD-licensed superset of functionality that builds on top of the YUI foundation.

Most current YUI components use "Custom Events" as their main communication pipes. This is good. Using custom events you can, for example, know when a YUI Panel is opened or closed, and the components in your application can subscribe a listener to this custom event to know when the Panel’s status changes.

YAHOO.example.myPanel.showEvent.subscribe(function(){  // your stuff here…});

The weakness of this model is that all the components in your application need to know about or have access to the YUI Panel object to subscribe a listener. Even worse, they all need to wait until the YUI Panel instance is created (because that’s when the custom event is created and becomes available for subscription), so they need to be aware of the timeline in the application. If you need to introduce a new component in your application, to attach a listener you must wait until the YUI Panel has been created. What happens if you have several panels instead of one? You keep adding more and more listeners, creating more dependencies, and more timeline control.

The solution for this overwhelming amount of complexity is simple and very useful for complex web applications. Those who are accustomed to high-level programming languages, blackbox programmers,and APIs fans will love this implementation for sure.

Decoupling

The idea here is to create components that do not need to know about other components in the application. Each component will catch certain messages (listening events) generated by another component, o create a new message (broadcasting events) based on the received message, and fire the new message to reach all the listeners. We’ll have an abstraction layer that will allow us to subscribe listeners for a specific message. For example:

YAHOO.Bubbling.on( 'onPanelShow', function(layer, args) {
    // do the job here…
});

In this diagram, we have two components that will broadcast a message to the abstraction layer (Custom Behavior Layer), reaching all the listeners for that specific message (keying on the message’s name).

Each component will also have three listeners (C1: B1,B2 and B3; C2:B4, B5, B2). In the case of the message B2, both components will be listeners for the same message, and both will be able to react when the message arrives.

What’s critical here is that we will be able to subscribe listeners to an undefined event, without worrying about what will fire this type of event or about what else might belistening for the same event. And this new listener will be executed whenever something (a component in your application) fires an event with the same name, in this case onPanelShow.

On the other hand, we will be able to fire an event, without previously defining it. For example:

YAHOO.Bubbling.fire ('onPanelShow', {  param1: value1,
  param2: value2});

This call will send a message to all listeners, passing the name of the layer and the literal object (second argument).

We can go one step further, and pass the YUI Panel’s reference in the literal object, and the listeners will be able to query the Panel instance’s data, check the panel name, etc. For example::

var myPanel = YAHOO.widget.Panel("win", {fixedcenter: true});

myPanel.showEvent.subscribe(function(){  YAHOO.Bubbling.fire (’onPanelShow’, {    panel: myPanel,
    param1: ‘value1′,
    param2: ‘value2′  });});

Each time the YUI Panel is displayed, a broadcast message will be fired, the name of the event will be onPanelShow, and the listeners of this type of event will be queried, using the panel, param1 and param2 as references. There are some interesting aspects to this example. You don’t need a global reference for the Panel object because there will be no subscribers attached directly to the YUI Panel object. Instead, we will subscribe the listener to the abstract layer (YAHOO.Bubbling). You can have more than one Panel, each Panel will fire the same event, and the listeners will be able to handle the broadcast without knowing anything about the Panel’s nature or environment. Finally, each subscriber will be able to define its execution scope, using the 3rd parameter:

YAHOO.Bubbling.on( 'onPanelShow', myListenerFunc, myScope);

Utilized well, this technique gives us the possibility to create a complex web application where each component will have an API to use for communicating with other components without knowing the component itself, or knowing the nature of the component.

Requirements

The Bubbling Library YUI Extension has already implemented this technique, so the requirements are simple:

<script type="text/javascript" src="http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js"></script><script type=”text/javascript” src=’http://js.bubbling-library.com/1.5.0/build/bubbling/bubbling.js’></script>

* Bubbling Core (6k minify version)

Other examples

• Creating a notification system that will handle application messages — displaying each message in a box on the bottom-right corner of the browser, with different backgrounds, all the components in your application will be able to broadcast a message; the notification system will catch the event and will display the message in the corresponding box, depending on the parameters sent by the sender.
• Creating a loading mask (just like Gmail) that will display the message every time that the YUI Connection Manager, the YUI Get Utitlity or the YUI Loader starts waiting for a response from the server. In this case, all the components will have access to the Connection Manager, and each component will need to fire the LOADING EVENT every time it uses one of the loading mechanisms.
• In a web app that supports multiple layouts — every time you switch the current layout, all the web parts will need to be notified in order to readjust the visual interface. All the components can define a listener to the switching action, and all will be notified with the name of the new layout to apply and new css rules isplaying or hiding certain information related to the component.
• In a webmail system, you need to be notified when a new message arrives or when an unread message has been read. There are some pieces of the application that would be interested in this event (inbox, messenger, the message counter, etc), but the reader panel don’t know which of these parts are present on the page.

Conclusions

• This technique is ideal for a large development teams. It reduces the complexity of the code and minimizes the number of global variables by eliminating the hard pipelines between components.
• Large applications with many dynamic areas are tricky when you need to control the loading timeline. Using this technique you don’t need to worry about the loading timeline.
• Applications based on this technique are easy to extend.
• Each component has a simpler API making it easier for other developers to understand and reuse.
• All the listeners will share the same syntax
  YAHOO.Bubbling.on('onEventName', function(layer, args) {});