Let’s start with some Flex 3 code we’d like to duplicate. This will create a “modal” overlay that covers the app with a translucent screen. You might use this for a LightBox.

<!-- MyOverlay.mxml -->
<mx:Canvas 
    width="100%" height="100%"
    styleName="overlay"
    >

    <!-- Put a panel or something here -->

</mx:Canvas>

/** styles.css **/
.overlay {
    background-color: #000000;
    background-alpha: 0.7;
}

Our First Skin

We want to create this in Flex 4. The (rough) equivalent to canvas is a Group, but it isn’t skinnable, so we can use a SkinnableContainer instead.

<!-- MyOverlay.mxml -->
<s:SkinnableContainer
    width="100%" height="100%"
    skinName="overlay"
    >

    <!-- Stuff -->

</s:SkinnableContainer> 

SkinnableContainer doesn’t have a way to set backgroundColor or backgroundAlpha! The css will not work.

Let’s create the same functionality in a skin instead.

<!-- skins/OverlaySkin.mxml -->
<s:SparkSkin ... >

    <!-- The highest-level base class that can use this-->
    <fx:Metadata>
        [HostComponent("spark.components.SkinnableContainer")]
    </fx:Metadata>
    
    <!-- specify all the states the host component uses -->
    <s:states>
        <s:State name="normal"/>
        <s:State name="disabled"/>
    </s:states>
    
    <!-- Here's our overlay! -->
    <s:Rect left="0" right="0" top="0" bottom="0">
        <s:fill>
            <s:SolidColor color="#000000" alpha="0.7"/>
        </s:fill>
    </s:Rect>
    
    <!-- Put the panel, or whatever is in the component here --> 
    <s:Group id="contentGroup" verticalCenter="0" horizontalCenter="0">
        <s:layout><s:BasicLayout/></s:layout>
    </s:Group>
    
</s:SparkSkin> 

That’s not too bad. We have a skin, and now we can apply it to our component by setting the skinClass property. For example:

<!-- MyOverlay.mxml -->
<s:SkinnableContainer
    width="100%" height="100%"
    skinClass="skins.OverlaySkin"
    >

    <!-- content -->

</s:SkinnableContainer>

Or we can set the skinClass in the style.

<!-- MyOverlay.mxml -->
<s:SkinnableContainer
    width="100%" height="100%"
    styleName="overlay" 
    >

    <!-- content -->

</s:SkinnableContainer>

/** styles.css **/
.overlay {
    skinClass: ClassReference("skins.OverlaySkin");
}

Using CSS on the Skin

Now we have a styleName we can apply to any SkinnableContainer and it will make it look like our black, translucent overlay. This works great, so we start using it, but pretty soon we realize that we need to be able to add a background to another container, but we don’t want to create a new skin just to tweak the color and alpha. Here is where it gets fun. We change the Rect tag in our skin to look like this:

<s:Rect left="0" right="0" top="0" bottom="0">
	<s:fill>
		<s:SolidColor color="{getStyle('backgroundColor')}" alpha="{getStyle('backgroundAlpha')}"/>
	</s:fill>
</s:Rect>

Now it will get it’s color and alpha from the style. We can change our overlay style to look like this

/** styles.css **/
.overlay {
    background-color: #000000;
    background-alpha: 0.7;
    skinClass: ClassReference("skins.OverlaySkin");
}

That looks a lot more like the Flex 3 version! We can then add more styles for other kinds of containers that need backgrounds, and our skin is now much more useful than before.

The Final Version

<!-- skins/BackgroundSkin.mxml -->
<?xml version="1.0" encoding="utf-8"?>
<s:SparkSkin xmlns:fx="http://ns.adobe.com/mxml/2009" 
             xmlns:s="library://ns.adobe.com/flex/spark" 
             xmlns:mx="library://ns.adobe.com/flex/halo">
    
    <fx:Metadata>
        [HostComponent("spark.components.SkinnableContainer")]
    </fx:Metadata>
    
    
    <s:states>
        <s:State name="normal"/>
        <s:State name="disabled"/>
    </s:states>
    
    <s:Rect left="0" right="0" top="0" bottom="0">
        <s:fill>
            <s:SolidColor color="{getStyle('backgroundColor')}" alpha="{getStyle('backgroundAlpha')}"/>
        </s:fill>
    </s:Rect>
    
    <!-- Tells the skin where to put the children you have specified -->
    <s:Group id="contentGroup" verticalCenter="0" horizontalCenter="0">
        <s:layout><s:BasicLayout/></s:layout>
    </s:Group>
    
</s:SparkSkin>

/** styles.css **/
.overlay {
    background-color: #000000;
    background-alpha: 0.7;
    skinClass: ClassReference("skins.OverlaySkin");
}

.error {
    background-color: #FF0000;
    background-alpha: 1.0;
}

.success {
    background-color: #00FF00;
    background-alpha: 1.0;
}

Using this technique will allow you to play to the strengths of both CSS and Spark Skins.

FlashLib.org Suggestions Source

Basic Features

Project Page Features

FAQ

How can I help?

Make suggestions on UserVoice. Follow me on twitter or subscribe to the blog feed for updates.

Please contact me if you’d like to help code up the site. You can also watch or fork the GitHub Repository. All of the site’s code will be public, so it should be easy to contribute. If you have something to submit, just contact me and I’ll pull from your fork.

What about OSFlash.org?

OSFlash.org only lists major projects. FlashLib will index tiny blog posts as well. FlashLib will also add all the spiffy democratic features

What about RIAForge.org?

RIAForge requires that projects be hosted with them. While they have a lot of good stuff there, they are missing many important things. We will use links to project pages instead of hosting.

What about GitHub?

We will link to GitHub projects. Not only does GitHub not provide all the features we need, but it locks people into git, and many projects are on SVN or just a blog post.

What about Google Code / SVN / Some other Repo thing?

Remember, we’re only linking to projects in other places, so we can link to ALL of them.

I have a great idea, how can I suggest it?

Please visit the UserVoice page and create the suggestion. Vote on others too!

What if two people use the same name or package?

This will generally not be a problem, but a simple email to the project author should be enough to get him to make his package names unique. Project names don’t have to be unique, but moderators can combine them if they are really the same project

Can I download a big library with all my favorite classes?

No. This is a bad idea. It makes more sense to download the swcs for each library separately. However, see the “Build” feature above.

What about dependencies?

First, dependencies are rare across libraries. However, libraries can easily include another library inside them. Flash knows how to handle it already. I assume this question stems from the desire to create an ActionScript library with a bunch of useful stuff inside that builds on itself. People can still create such libraries. They would be indexed as one project in flashlib. They can also split something like that out into several libraries. Either way it will work.

Why not just use Jeffery’s Underware?

Jeffery has created a great tool here, but it concentrates on downloading the latest code, not discovering it. It also is locked in to SVN.

Why not just use a wiki?

Wikis are cool, but they do a poor job filtering and sorting information. This will be much like a wiki, but will have extra features.

Update - I’ve begun work on this at flashlib.org

Update - I’ve listed the planned features and made a FAQ page

The Standard Library

As far as I understand, Ted means someone should create one swc file containing many classes to solve a wide variety of problems. The advantages of this approach are that people can download the library and use the best solutions available without having to hunt around.

There are several disadvantages, though.

1. The library will grow stale because the maintainers don’t have an infinite amount of time to check out new stuff. It will have momentum at first, but will become less relevant over time.

2. Many good ideas will not be included. The library can only include robust solutions, preventing one person from beginning something and another finishing it. Someone unknown may have a good solution that never gets in because it doesn’t quite meet standards.

A Better Approach

The monolithic library is a temptation that should be avoided. A better approach is to keep libraries focused and small. This makes it easier to mix and match solutions to exactly fit your project’s needs.

However, we still need a way to find these small solutions. I propose a community site dedicated to finding good libraries and classes. At first glance, I think it should have the following features.

1. Links to projects rather than hosting them

2. List of alternative projects

3. Ratings and comments

4. Community editable project pages

5. Reputation System

This will solve the same problems without the disadvantages. With a democratic approach, the very best will naturally rise to the top, people can extend each other’s work, and the authors don’t even need to directly participate for it to be effective.

If this idea gains enough steam, I volunteer to create the site. What do you think? What other features should it have?

Flog (Flex Logging) on Github log.as SharedObjectTarget.as

There are two files in there now. The first is log.as. I didn’t realize before that it was possible to define your own package-level functions. Some might disagree with me, but I think this syntax is a lot nicer than the default. It looks just like trace. All it does is create an easy way to access the flex logging api.

import net.seanhess.flog.log;

function stuff():void
{
    log("Executing stuff");
    // do stuff 
    log("Finished!");
}

You can replace all your trace statements with these. It’s easy enough to add a trace target to the logging api, so all log messages are traced. See the Flex Logging API for more details, but here’s how you would do it.

import mx.logging.Log;
import mx.logging.targets.TraceTarget;

// Only once in your app
function addLoggingTargets():void
{
    Log.addTarget(new TraceTarget());
}

The second little tool is a new logging target. I wanted a way to log to a local file in flex, so the support guys could get an end-user to email it. The only way to do this without hacks is to write to a shared object. It turns out if you write an array of strings to a shared object, it’s easily human-readable. You attach SharedObjectTarget like any other target and away you go.

import mx.logging.Log;
import net.seanhess.flog.SharedObjectTarget;

// Only once in your app
function addLoggingTargets():void
{
    Log.addTarget(new TraceTarget());
    Log.addTarget(new SharedObjectTarget("MyCustomAppLogging"));        
}

The file is located in the application data folder, which is in ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects on the mac. (Google it for windows). The target does some fancy stuff like automatically saving if it hasn’t received a log message for one second. It also automatically rotates messages once the size reaches about 50k (The default allowed size for shared objects is 100k).

There’s more that can be done here. I might add a debug and an error function. You could easily write an app to send the contents to a server too.

For alternatives and more information look at the approaches of Tom Barker, Virgil Cristea, and John Wilker.

You may not have realized that PHP is itself a templating engine. It allows you to intersperse logic and text, and has some handy features to make it easy. I’m going to show you how to build a php-based templating framework in one file.

Please read Template Engines and Beyond Template Engine for background and other approaches to the same thing. They specifically address why you would want to use PHP instead of another layer for templating.

The final product

SimpleTemplate.php

post.php?id=2

<?php

    require_once('SimpleTemplate.php');

    $post = new BlogPost($_GET["id"]); // pretend we're fetching a post from a db
    $main = new SimpleTemplate("templating/post_full.php");
    $main->post = $post;
    $main->comments = $post->comments;

    $layout = new SimpleTemplate("templating/main_layout.php");
    $layout->title = "Post - $post->title";
    $layout->content = $main->run();

    echo $layout;

templating/post_full.php

<h2><?= $post->title ?></h2>
<p><?= $post->body ?></p>
<hr>
<? foreach ($comments as $comment): ?>
<p>Comment - <?= "$comment->name - $comment-text" ?></p>
<? endforeach; ?>
<!-- Add a comment form here -->

templating/main_layout.php

<html>
<head>
    <!-- some script tags, css, etc -->
    <title><?= $title ?></title>
</head>
<body>
    <h1>This is my site</h1>
    <?= $content ?>
</body>
</html>

It’s simple to use, and requires nothing but basic php skills (maybe with the addition of knowing you can do that colon trick with loops).

How to make one?

It’s simple, really. First let’s create the class, and add 3 fields. source will store the variables, path is the path to the template, and result contains the generated result.

class SimpleTemplate
{
    public $source;
    public $path;
    public $result;
}

The main essential feature is that the engine include another php script and capture its output. You can easily do that with php’s output buffer functions. Let’s create a “run” function that will return the template’s content. Anything printed or echoed between ob_start() and ob_get_contents() will be stored in $this->result.

public function run()
{
    ob_start();                         
    extract ($this->source); 
    include $this->path;
    $this->result = ob_get_contents();
    ob_end_clean();
    return $this->result;
}

Next we need a way to store some variables so that extract call works. extract takes the variables available in a certain scope and empties them into the current scope. So, we can set $template->title = "a title"; and that variable will be available in our template as $title. We’ll implement php’s magic __set() and __get() to do this.

public function __set($name, $value)
{
    $this->source[$name] = $value;
}

public function __get($name)
{
    return isset($this->source[$name]) ? $this->source[$name] : "";
}

Now that extract call will work as explained above. Finally, let’s add a __toString() method so we can just print $template; and use string concatenation and go nuts. Let’s also add a constructor that stores the $path variable.

<?php

class SimpleTemplate
{
    public $source;
    public $path;
    public $result;

    public function SimpleTemplate($path=false)
    {
        $this->source = array();
        $this->path($path);
    }

    public function __toString()
    {
        return $this->run();
    }

    public function __set($name, $value)
    {
        $this->source[$name] = $value;
    }

    public function __get($name)
    {
        return isset($this->source[$name]) ? $this->source[$name] : "";
    }

    public function run()
    {
        ob_start();
        extract ($this->source);
        include $this->path;
        $this->result = ob_get_contents();
        ob_end_clean();
        return $this->result;
    }
}

You can get more fancy if you like. In the full example I added parents for templates, meaning they can access variables from their parent’s scope. I also added the extract method, which copies all the variables in an object into the scope (it saves a few characters).

Daemon source files

daemon generate_feed.php start
daemon generate_feed.php stop     
daemon generate_feed.php restart

generate_feed.php might look like this

require_once("BlogDatabase.php");
echo "Generating Feed"; // this will go to the log  

$data = new BlogDatabase();
$posts = $data->getAllNewPosts();

foreach($posts as $post)
{
    // generate an rss feed
}                          

file_put_contents("feed.xml", $contents);

Alternatives

• crontab - This is the easiest way to get a script to run on a timer, but there are a few disadvantages. Specifically, you don’t have exact control over the timer, nor can you prevent the script from running if the system isn’t ready. Refer to this article for more information.

• System_Daemon - This was built using System_Daemon. I created this because my daemons were behaving strangely. Our database calls weren’t working properly, and things were just generally messed up.

What it does

This uses the pear System_Daemon to create a daemon that runs your script every 5 seconds (by default). It uses shell_exec to run it, giving you the following advantages.

• Your script runs in a “sandboxed” environment. You don’t have to worry about stale variables or strange processes making your code behave strangely.

• You can test your script by running it on the command-line, since this is exactly what the daemon does.

• You can easily start and stop the daemon using the included tool.

• It puts output from the script into the daemon’s log (/var/log/generate_feed.log on my system)

Sorry it isn’t more flexible right now, but the timer can be easily changed in Daemon.php

Installation

You need to install the pear System_Daemon module. Refer to this article for instructions.

Put your daemons in the same folder as these scripts, or else make sure Daemon.php is in your include path when you run daemon from the command line.

Source on Github

I used sequel as the ORM for this blog. I had originally wanted to use DataMapper, but I ran into some problems. They’re pretty similar anyway.

First, we need to give the connection information to Sequel. I put my database info in a yaml file because I wanted to be able to pass the command-line migration tool the same info. I require this file from my “controller”. It’s important to remember that the following files aren’t a sinatra standard or anything. You can organize your files however you like.

data/init.rb

require 'rubygems'
require 'sequel'
require 'yaml'

content = File.new("data/database.yml").read
settings = YAML::load content
DB = Sequel.connect "#{settings['adapter']}://#{settings['username']}:#{settings['password']}@#{settings['host']}/#{settings['database']}"

require 'data/models'

data/database.yml

adapter: mysql
host: localhost
username: root
password: root
database: custom_blog

Here are my models. The syntax of these models will look similar to active record. There aren’t much to them. A few things to notice are that I used simple many_to_many and one_to_many associations.

data/models.rb

require 'rubygems'
require 'sequel'

class Post < Sequel::Model
  Page = "page"
  Post = "post"

  many_to_many :tags
  one_to_many :comments

  def date
    created.strftime "%B %d, %Y"
  end

  def summary(length=300)
    body.gsub(/(<[^>]*>)|\n|\t/s," ")[0..length]
  end

  def update_title(value)

    raise "[ ! ] Could not find title for post" if value.nil?

    self.title = value
    self.name = value.downcase.gsub(/[^\w]/,"_").gsub(/__/,"")
  end
end

class Tag < Sequel::Model
  many_to_many :posts, :order => :created.desc
end

class Comment < Sequel::Model
  many_to_one :posts

  def post
    Post[:id => post_id]
  end
end

These behave as expected. The syntax is only slightly different from active record. Sequel allows you to chain commands to a dataset together, which makes it easy to create complex queries.

Post.all
Post.first.comments
Post.filter(:kind => Post::Page).reverse_order(:created).all
Post.first.tags

I’ll give you more concrete examples when we cover the controller. The next thing to look at is the migration. Now, I don’t really like migrations, but until these ORMs add support to dynamically update the database schema, I’m stuck with them. Here’s where I’m at currently.

data/001_BaseSchema.rb

require 'data/models'

class BaseSchema < Sequel::Migration
  def up
    create_table! :posts do
      primary_key :id
      String :title
      Text :body
      Time :mtime
      Time :created
      String :kind, :default => Post::Post
      String :file
      String :name
    end

    create_table! :tags do 
      primary_key :id
      String :name
    end

    create_table! :posts_tags do
      primary_key :id
      foreign_key :tag_id, :tags
      foreign_key :post_id, :posts
    end      
  end

  def down
    drop_table :posts
    drop_table :tags
    drop_table :posts_tags
  end
end

data/002_Comments.rb

require 'data/models'

class Comments < Sequel::Migration
  def up
    create_table! :comments do
      primary_key :id
      foreign_key :post_id, :posts

      String :name
      String :email
      String :url
      Text :body
    end
  end

  def down
    drop_table :comments
  end
end

To run the migrations, you use the sequel command-line tool. Here, I’m telling it to run migrations from my data folder, and to use data/database.yml for connection info.

sequel -m data data/database.yml
sequel -m data data/database.yml -M 1 # migrates to 001

That’s it for now!

1. Use selectedIndex - You can throw your pages/containers in a ViewStack and store the currently selected page index in a model. This works great, except that your model is coupled to the order of the pages in the ViewStack. You can store the indices in constants, but if someone adds a new page in there, it will throw off all the indices.

2. Use selectedChild - You can mitigate the index problem by storing the selectedChild property on your model, but then your model has a reference to a view. Yuck.

The solution - Page Stack

This simple component allows you to store the name of the selected page. You can set the page. You can then store a string on your model that you bind to the selectedPage property of PageStack. If you set the name on each child of the PageStack, they’ll match up.

MyView.mxml

<components:PageStack selectedPage="{navigation.selectedPage}">
    <mx:Canvas name="{Navigation.FIRST}"/>
    <mx:Canvas name="{Navigation.SECOND}"/>
    <mx:Canvas name="{Navigation.THIRD}"/>                
</components:PageStack>

<mx:Button label="Go to Page 3" click="navigation.selectedPage = Navigation.THIRD"/>

Navigation.as

public class Navigation
{
    public static const FIRST:String = "first";
    public static const SECOND:String = "second";
    public static const THIRD:String = "third";
        
    [Bindable]            
    public var selectedPage:String = FIRST;
}

And here’s the source!

package net.seanhess.components
{
    import flash.display.DisplayObject;

    import mx.containers.ViewStack;
    import mx.core.Container;

    public class PageStack extends ViewStack
    {
        protected var pages:Object = {};
        protected var newChildren:Boolean = false;

        override public function addChildAt(child:DisplayObject, index:int) : DisplayObject
        {
            newChildren = true;
            invalidateProperties();
            return super.addChildAt(child, index);
        }

        override protected function commitProperties() : void
        {
            super.commitProperties();

            if (newChildren)
            {
                newChildren = false;
                pages = {};

                for each (var child:DisplayObject in getChildren())
                {
                    var name:String = child.name;
                    pages[name] = child;
                }
            }
        }

        public function set selectedPage(value:String):void
        {
            var child:Container = pages[value] as Container;

            if (!child)
                throw new Error("Could not find page: " + value);

            selectedChild = child;
        }

        public function get selectedPage():String
        {
            return selectedChild.name;            
        }
    }
}

# myview.erb
<% form("/login", :post) do %>
	<p>Username: <input type="text" name="username"></p>
	<p>Password: <input type="password" name="password"></p>
<% end %>

# helpers.rb
def form(url, method, &block)
  @_out_buf << "<form action='#{url}' method='post'>"
  @_out_buf << "<input type='hidden' name='_method' value='#{method}'>"
  yield
  @_out_buf << "</form>"
end

A few weeks ago I sat down with Michael Jackson (no, not that one). He showed off his new blog, written from scratch in one week, and I was instantly jealous. I’ve been using wordpress for more than a year, and although it’s a good system, I was always intimidated out of customizing it.

Well, a few weeks later (it took me longer), and hundreds of dollars of time poorer, here it is.

Download the code on github

How does it work?

I’ve been dabbling with ruby for a year now, but haven’t had the chance to put anything into production. The site was created using Sinatra - an incredibly slick, performant ruby DSL. I used erb as the templating language, and Sequel as my ORM.

One of the coolest things about it, which I totally ripped off of Michael, is that all the posts are written as flat markdown files, rsynched to the server. Metadata for the posts is at the top of the file, and the files are converted to html only if they’ve changed. All it takes is one cap deploy. Here’s an example of what a post looks like

Title: A New Home
Tags: Ruby, Code, Site

My blog has been going through a state of flux lately. I hadn't posted in a couple
of months, and when I discovered [posterous](http://posterous.com), I thought...

Ruby FTW

Back a few months ago, I was just starting to get sick of trying to learn rails. It had been nearly a year since I started, and I still didn’t get it. To top it off, I had been forced to use php for another project at work, and it felt so refreshing I swore I’d never go back.

I started to realize that there are other ruby frameworks out there, including Merb, Ramaze, and Sinatra (discovered in that order). Leaving rails behind was the best thing I ever did. I learned ruby. Ruby is awesome.

Design

I also designed the thing from scratch. The design was definitely inspired by many on The Best Designs. I used Blueprint, which made the css way easier. I took some icons from Dry Icons and the background image from Echo Enduring.