nhusher

    grunt.initConfig({
        // Runs the YUI3 build tool on a directory. Docs: <http://yui.github.io/shifter/>
        "shifter": {
            "crm-src": {
                // (optional) version - What to fill in on the "@VERSION@" field in built files
                "version": "CRM",
                // (optional) lint can be 'config' or false
                // if "config", shifter will use the nearest .jshintrc JSON file as JSHint config
                // if "false", shifter will skip the lint step entirely.
                "lint" : "config",

caridy

This gist was updated based on the discussion here : https://groups.google.com/forum/?fromgroups=#!topic/yui-contrib/cUpVvtoUBa8

Template Registration

With the ability to precompile templates into javascript and the abtraction layer provided by Y.Template to normalize the api to render those templates, we got one step closer to create applications that can be template language agnostic.

The premise here is to create a YUI Application that references templates by name and call for render when needed without having to know what engine to use, or what file generated the compiled template, or what api should be used for a particular template.

In order to facilitate this, we should have a centralized registration mechanism used by the application to register any template that is provisioned, in which case we can decouple the provisioning process from the actual rendering process.

ericf

Y.Guest = Y.Base.create('guest', Y.Model, [Y.ModelSync.REST], {
    root: '/guests/'
});

Y.Guests = Y.Base.create('guests', Y.ModelList, [Y.ModelSync.REST], {
    model: Y.Guest
});

Y.Invitation = Y.Base.create('invitation', Y.Model, [Y.ModelSync.REST], {
    root: '/invitations/',

juandopazo

Storage

Motivation

There are 3 major types of storage is browsers up to date:

• IndexedDB. The future.
• localStorage. Limited in size and can be observed through the storage event.
• WebSQL. Dropped by the W3C but it's still very present in the wild, with notable platforms like iOS and PhoneGap.

Satyam

// How to use it.
//
// This code is based on the template file that YOGI produces for unit testing 
// when a module is created.  Only the main changes to it are listed.
//
// Add a reference to the module in the YUI configuration section so it can locate it
// It's up to you where you put it.
YUI({
    groups: {
        leaks: {

cstrahan

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC
        "-//Apple//DTD PLIST 1.0//EN"
        "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>homebrew.mxcl.bitlbee</string>
<key>ProgramArguments</key>
<array>

ericf

#!/usr/bin/env node

var fs   = require('fs'),
    path = require('path'),

    yui_module = process.argv[2] ? path.join(process.cwd(), process.argv[2]) : 'yui',
    output     = process.argv[3],

    EXCLUDE_FILTERS = [
        /^cookie/,

davglass

New YUI Feature Detection

This is my proposal for revamping the YUI Core Feature detection system.

Problem Space

• 90% of our so-called "Feature Tests" are actually Loader conditional modules.
• Some "free-flowing" tests in DOM modules.

ericf

{
    "align_indent": false,
    "alignment_chars":
    [
        "=",
        ":"
    ],
    "alignment_space_chars":
    [
        "="

derek

Scenario

I want to use YUI inside of a WebWorker thread. Flickr recently wrote a post on this very topic, Web workers and YUI.

Problem

But I want to use YUI's CDN, which WebWorkers prevent because it enforces a same-origin policy with importScripts()

Solution