We’ll be online on Thursday from 10am to 11am PDT.
We’re going back to using Adobe Connect this week because the broadcast resolution from Google+ Hangouts on Air was a bit low, and we’d like the chat to be more accessible for non-IRC users. Let us know if you agree or disagree in the comments.
Over the last few weeks, I have spent a great deal of time getting YUI’s core tests executing on Travis CI. As of today, every push to our YUI 3 repo on GitHub results in over 6,000 (6,053 to be exact) unit tests being executed and logged. These tests include 1,130 of our core JavaScript-only unit tests executing natively inside of Node.js on versions 0.4.x and 0.6.x (with 0.7.x support to be added soon). We follow that with our full unit test suite (4,923 tests), running with my command-line YUITest/PhantomJS wrapper, Grover.
Today I want to tell you a little more about how and why we are doing this.
Why?
For the longest time, our tests and builds were a mystery to our users. They all happened behind closed doors and nobody really knew what we were doing. Over the last few years, we started adding more and more of our tests to our source tree, so that people can see what we are actively testing. This helped a little, but it didn’t show that we run every test on every build and that if a test fails, we don’t push that build to GitHub.
Then along came Travis CI, the open source continuous integration platform that hooks directly into GitHub. I played around with it for a day and immediately began moving our tests around so we could use it. We want to be more transparent in our processes and allow the public to see what we test and how we do it.
One thing we want to add to this process is access to our current code coverage report. Currently, we run a code coverage report daily from tests executed in FF12, Chrome-latest and IE8, but none of our users can see that we are at ~80% covered:
We are working very hard to rectify this issue and hopefully get this data out in the open for everyone to see.
How?
I had to make minimal changes to our core test suites in order to get them to run under Node.js in Travis CI. By “core test suites”, I mean any YUI module that can execute without the need for a working DOM. This includes, but is not limited to: YUI Core, Loader, YQL, Y.Array, Y.Object, etc. These modules are all perfectly usable inside of Node.js without modification.
All I had to do was create a Node.js wrapper similar to the standard test wrapper we use in a browser and include the exact same test that’s executed in the browser.
Here is the YQL module’s wrapper:
Now, this same test module can be executed in a browser and in Node.js without modification!
Caveats?
In order for these tests to run natively in Node.js, they need to not interact with the DOM. For example, Y.Array consists of helper methods for dealing with Arrays in JavaScript. But there are a few tests that include dealing with DOM elements to ensure that the helper methods return the right values. For these tests, I had to move the DOM-related code into a new test and add that test to the list of ignored tests when Y.UA.nodejs is detected. This way, such tests are ignored in Node.js, but still run in the browser.
Here’s an example:
As you can see, it’s relatively easy to make our tests run in both environments to ensure that our code is stable and fully functional when used in Node.js as it is in the browser.
What is Grover?
Grover is a command-line tool that allows you to execute YUITest-based tests in PhantomJS. PhantomJS is a headless Webkit instance that allows you to render an HTML page without a GUI present. So Grover closes the gap on this and allows you to run our unit tests from the command-line inside of a CI system like Travis.
Grover is free and available via: npm install -g grover (You must have the PhantomJS binary installed before using Grover.)
How do we see all this?
Travis CI provides a full report of previous builds, as well as an up-to-date status information. Below are the links to our current projects hosted on Travis CI:
We are trying out the new Travis/GitHub Pull Request feature on all of our projects. This means that whenever a developer submits a Pull Request to us, Travis will automatically pull their code, merge it into master (on their server) and run our full unit test suite against it. Their “Travis Bot” will automatically post a comment back to the Pull Request telling the developer whether or not their patch passed its tests.
Here’s an example of a Pull Request passing:
And one where it fails:
What’s next
We plan on adding support for executing our tests with Yeti as soon as it becomes stable enough to run on each build. We are also looking into deploying our code coverage numbers as well. Other than that, feel free to tell us in what other ways we can be more open than we are now.
I, for one, am very happy with all of these new features and I hope you are too!
We are pleased to announce the availability of YUI 3.6.0 PR1 for community testing and feedback. Please take a moment to check it out via CDN or download.
Here are the target dates for all YUI 3.6.0 milestones:
PR1 – May 8, 2012
PR2 – June 12, 2012
PR3 – July 17, 2012
GA – July 31, 2012
An overview of items we are working on for YUI 3.6.0 include:
ScrollView enhancements
DataTable features and performance improvements
Charts bug fixes
Image preview feature in Uploader
Popup Calendar
YUI seed and global refactored for performance
We are also taking steps to condense our development cycle so that we can transition to monthly releases in the near future.
Today we are pleased to announce the official release of the new YUIDoc, our JavaScript documentation generator. YUIDoc is a Node.js application that generates API documentation from comments in source, using a syntax similar to tools like Javadoc and Doxygen. YUIDoc is currently powering the API documentation for YUI and has been actively updated over the last year.
Live previews. YUIDoc includes a standalone doc server, making it trivial to preview your docs as you write.
Modern markup. YUIDoc’s generated documentation is an attractive, functional web application with real URLs and graceful fallbacks for spiders and other agents that can’t run JavaScript.
Wide language support. YUIDoc was originally designed for the YUI project, but it is not tied to any particular library or programming language. You can use it with any language that supports /* */ comment blocks.
Some of the new features added to this version are:
Markdown support in code comments
Support for many more tags out of the box
Logic separated to allow for easy extensibility
Better theming support
Server mode for development time previews
External data mixing
Easy cross platform installation
Cross-linking inside and out of current project
JSON based configuration
Let’s get into a little more detail on some of these:
Simple Installation
If you have Node.js and NPM installed, installation is easy:
npm -g install yuidocjs
Markdown support in code comments
YUIDoc will parse your comment with Markdown before it applies the Handlebars template giving you great flexibility when writing your docs.
Logic separated to allow for easy extensibility
YUIDoc uses YUI’s class infrastructure internally and exports all of these modules when you require the yuidocjs module. This allows end users to hook into YUIDoc’s internals and change the way it does things. You can extend classes, augment them or just flat out change methods to suite your needs.
Better theming support
In this release we use the built-in Y.Handlebars helper to handle all template generation. We have also taken development into consideration when building this feature. YUIDoc will first search it’s built in theme directory for partials, then it will search your local theme directory. This allows you to only have to maintain the files you wish to change in your theme and not have to copy every partial even if you are not modifying it.
Server mode for development time previews
This is my favorite new feature! You can fire up YUIDoc in server mode and it will give you live previews of your documentation as you edit it. Simply save your file and reload the page from the built in server and see your changes live. Including external data and cross-linking. You no longer have to generate the docs for your entire project just to see a documentation change!
External data mixing
YUIDoc now allows you to link your documentation to the rendered output from another YUIDoc instance. For example, if your project is using YUI and extending some of our core classes, you can link to our exported data.json file (from our YUIDoc build) and when YUIDoc parses your documentation it will fetch our data and cross-link all of your extended classes back to ours. This way you don’t have to document another projects code, you simply point over to their docs like it was part of yours.
Project Changes
All future YUIDoc development will be fully conducted on Github. We will be tracking the project on their wiki and using their issues to manage our tickets. It will be run like a native Node.js project completely in the open. We will also be using a Google Group for support requests, so sign up today!
We are also happy to report that YUIDoc’s unit tests are hosted on Travis-CI and will run per Github push!
The old Python source for YUIDoc is in a branch on the current Github repo where it will remain indefinately. There are no plans on accepting any pull requests or making any updates to that code base.
Uploader was another component that saw a major upgrade in 3.5.0. Of the many changes, one big one was the addition of support for native features in browsers supporting HTML5.
Join us for a discussion with its author, Allen Rabinovich, in which we’ll talk about how Uploader is structured, some of the challenges with modern techniques that needed to be addressed, and what’s on the roadmap for upcoming versions.
Time & Details
We’ll be online on Thursday from 10am to 11am PDT.
This week, we’ll be trying out Google Plus Hangouts on Air, so the audio and video feed will be through G+, and we’ll be monitoring chat in the #yui IRC channel on freenode.
Recently, there was a question in the forums about using input fields in a DataTable. With the ongoing push to build ever more complex applications in the browser, I decided that an overview of the available options for editing tabular data might be useful.
The most straightforward way to edit data would be to use inline editing, but this is not yet available in YUI 3 DataTable. In the mean time, one option is to roll your own input fields directly in the table cells, similar to this example.
If you do not want to save each change when it happens, you could use the QuickEdit gallery module instead. This lets you edit all the visible cells and then save the changes in a single operation.
The above solutions are modal. If you prefer a non-modal way to edit all the cells, you could use the Bulk Editor widget. This works with pagination, so you can save all the changes across all the pages of your table in a single operation. It even lets you easily add and remove rows — and even when you are using a remote DataSource!
Bulk Editor is not built on top of YUI DataTable, however. If you need other features from YUI DataTable, you could use the state preservation plugin for YUI 3 DataTable. This also works with pagination, so you can save all the values on all the pages in a single operation, but it is not designed to let you easily add or remove rows.
The state preservation plugin is also useful if you want to do something simpler like displaying checkboxes for selecting rows in a table.
The reason for all these different solutions is that the engineering trade-offs are quite complex, so it is not advisable to build a single kitchen sink solution to support all the above features. Hopefully, this overview will help you choose the appropriate module for tackling your next big table-based application.
About the author:John Lindal (@jafl5272 on Twitter) is one of the lead engineers constructing the foundation on which Yahoo! APT is built. Previously, he worked on the Yahoo! Publisher Network.
DataTable has been one of YUI's most heavily used and relied upon widgets for years. In 3.5.0, DataTable got a major overhaul, resulting in some small changes to the API and some big changes to the infrastructure.
In this two part article, we'll talk about these changes, what led up to the decision to revisit the infrastructure rather than focus on features, break down some of the new and experimental concepts being explored, and finish up with a look at the plan for the future of DataTable as we see it today.
So without further ado, let's address the obvious question:
Why Refactor?
The short answer is "to make DataTable easier to use and customize". The 3.4.1 infrastructure was based on a "core" Widget model, with all additional features left to plugins or subclasses. The data was held in a Y.Recordset instance and the column configuration in a Y.Columnset instance. The Widget was responsible for creating the entire table markup. That seemed like a reasonable architecture, but there were a few issues with this:
DataTables are defined by their features, which means there could be a lot of plug()ing to get the DataTable that fits your application. This made working with DataTable too complicated and verbose.
The contract of the Plugin API hindered DataTable's multiple features from interacting properly. In fact, certain DataTable features in 3.4.1 had already started breaking this contract.
DataTable was hard coded to use Y.Record, Y.Recordset, Y.Column, and Y.Columnset. This coupling limited the ability to customize DataTable or integrate it with other components in your application.
The rendering algorithm was flexible, but its hooks for customization were fixed. There was an opportunity to make rendering more customizable (and a whole lot faster) without requiring implementers to do major surgery on their instances.
The new architecture aims to address these and other issues uncovered during its production life prior to 3.5.0, and take advantage of the App Framework components that weren't around when DataTable was initially created in 3.3.0.
DataTable is incredibly important to a lot of people, and it's important to us that it not only be built right, but also that it be as easy to use as possible. These changes aim to move DataTable in the right direction.
Big Changes
The major changes from 3.4.1 to 3.5.0 are mostly under the hood, and with any luck, migrating to 3.5.0 DataTable should be painless.
Most of the outward changes to the API make it much easier to add and use DataTable features. Compare a 3.4.1 sortable DataTable to its 3.5.0 equivalent:
