Building an admin area for this functionality, the first thing I did was turn on admin routing.

Since we're logging in Users, we build a User model and UsersController. In the User model, write whatever extra you need, but the basics is just a validation function, to match username with password when logging in.

function validateLogin($data) {
    $user = $this->find(array(
        'username' => $data['username'],
        'password' => md5($data['password'])
        ), array('id', 'username'));
    
    return !empty($user) ? $user['User'] : false;      
}

You can add any additional validation rules in here, and you might want to use a better hashing use than simpy straight md5. Anyhow, this function will be called from the UsersController. So let's dive into there.

UsersController

Throw together a simple login function. I'll let your imagination put together the view, that's just some simple html form stuff. Check for post data, validate with the above function, write the User object to the session and redirect to the admin area.

And conversely, logging out is simply destroying the User object from the session and redirecting out of the admin area. Simple stuff.

To help enforcelogging in though, we pay attention to the filter event of controllers, and check the session first. The process of a controller responding to the router is beforeFilter -> action -> beforeRender -> render -> afterFilter. You can make sure things happen before it calls any action, by writing a beforeFilter method. You could use this method to check for things, and if it's not up to snuff, redirect to a different page. That's what we're going to do.

So, in the UsersController, we want to make sure that a user can't do anything pertaining to users until they login.

function beforeFilter() {
    if($this->action != 'login' && $this->action != 'logout') {
        if($this->Session->check('User') == false) {
            $this->redirect('login');
            $this->Session->setFlash('The URL you\'ve followed requires you login.');
        }
    }
}

Admin Requires Login

The last step is ensuring that any time a user wants to access the admin part of our app, they must be a logged in user, or they the boot. This involves using the same event as above, but in the AppController. The AppController lets us write something that should happen in every controller, because by default we should be extending AppController.

However, we don't want it to alwaysbe forcing logins. Visitors who access public areas shouldn't have to login. But if they want to access the admin areas, that's when we want to force them.

With our admin routing turned on, any time the Router wants to invoke a method because of the Routing.admin configuration, it will add to the params of the controller 'admin' = 1. Thus, we can easily make our filter only care if admin is set.

class AppController extends Controller { 
    function beforeFilter() {	
        if ($this->params['admin']) {		            
            if($this->Session->check('User') == false) {	
                $this->flash('The URL you\'ve followed requires you login.','/login',2);	
            }	
            $this->layout = 'admin';	
        }	
    } 
}

Admin Galore

Now, any page we want to setup as requiring admin access, like in my CMS, allowing admins to edit pages, we create functions prepended with value in your config for Routing.admin. By default, that's admin.

This simple addition now requires you be logged in (with a user made either manually by myself or using a registration form you can build into the UsersController) in order to see the list of pages.

class PagesController extends AppController {
    function admin_index() {
        //setting the layout could be done in
        //the AppController beforeFilter, so all
        //admin pages use the admin layout instead.
        $this->layout = 'admin';
        
        $this->set('pages',$this->Page->getNav());	
    }   
}

The default view for this follows the same kind of automagic rules for CakePHP: it'll be app/views/pages/admin_index.ctp.

Monstar Code

I've toyed around with various schemes, and have settled on my preferred colors. It might be influenced from the first time I used an editor in college (Eclipse), but it's changed and grown some.

I recall some people at my former work quite liked the inverted look. You know, light colors on a black or dark grey background. I wanted to like it: it kinda seems cool. But ultimately it was a little too weird for me.

However, this is a shot of my color scheme in Komodo (I try to duplicate the scheme in any editor I use).

I'll list the colors I use:

• Keywords - Blue. This would things like public, function, true, false, null, if, for, return, etc.
• Variables - Light blue.
• Strings - Green.
• Operators - Black. Arithmetic, assignment, parenthesis, the like.
• Numbers - Dark Brown.
• Comments - Grey. I prefer comments to be more hidden unless I specifically want to read them.
• Identifiers - Black. These are function calls, or accessing properties of objects.
• Standard Library - Red. Methods or constants defined in the standard library, I like them to stick out so I know when I'm using native functions (ex:print_r, preg_match, etc).

You'll also see that I enjoy a slightly off-white background, to cut down on the extreme photon abuse of my eyes. Just feels less... painful.

Other Editors

Komodo (seen above) doesn't allow me to do my last list item, coloring standard library names. I certainly wish it did, and if you know how, please do tell. However, I also use UltraEdit as it opens faster and uses less memory, and it doesallow me to set standard functions red. I believe Eclipse allowed me to do this (it's been a while use I've used it), and my recent checking out of Aptana showed it was possible.

In fact, Aptana seemed to have the more power for customizing color schemes. Not only could you select colors for groups of syntax, like 'keywords', you could then drill into keywords and say specifically that for and while should be different colors.

Besides Color

When given the option, I also enjoy when an editor allows me to modify the fonts of specific syntax. I like making comments italic, as it just seems to help make them... sleeker, more invisible, except when I need them. I don't use it personally, but I could see benefit to maybe adding bold to identifiers, or keywords, to make sure you don't miss out on any returns, for instance.

Of the many differences between coders, syntax highlighting is nearly a constant. However, coloring styles differ, as certain colors might have different psychological effects on the viewer. How do youprefer to look at yourcode?

Security? Pfft, I'm not too worried about people's to-do lists being stolen.

But what you didn't account for, is that all those username/password combinations a hacker just made off with? Yea, those are the same login's to important stuff, like e-mail , or bank accounts . Yikes!

Worst Case Scenario

Most users of the web don't think this hard about their own security, and even those that do, it's too complicated to remember a unique username and password for every single web-site you visit . And most of those users that don't know much about security also don't realize the need for using complicated passwords. So if you're collecting usernames and passwords, you need to design for the worst possible scenario:

Password: password1

Just Hash It All

So hopefully, the first thing you're thinking is that you shouldn't store your passwords in plain text. Good idea. You were thinking a hash, right? Because 2-way encryptions has it's own security problems. Once a user discovers the encryption key, they can decrypt every password you have. So let's hash everything.

There's plenty of debate about the best hashing algorithms, so for sake of simplicity, I'll just use md5*. But we're not going to use the straight output of the hash. That's like storing plain text. Instead, we'll make sure we use a nice salt.

Not any salt. Nothing like "NaCLS4lt". No no, that also makes it too easy for hackers to precompute. Instead, we're going to generate a random salt for every single password. So even if they manage to crack just one password, they haven't gained the salt for the rest of the hashes.

$salt = substr(md5(uniqid(rand(), true)), 0, $saltLen);

We grab a nice, random string that gets hashed, and this garbled text becomes our salt.

$hash = md5($salt . $plain);

Optionally, here you could do some manipulation, like splitting the password in half, or adding some salt to the end. The same goes for this entire process. The more you can mix it up without trying to come up with your own hashing algorithm, the more non-standard your passwords become.

Now then, we need this salt for later use, or else we'll never be able to regenerate this hash when a user logs in! We're not ganna store it in a seperate database field called salt. That gives it straight away to the hacker. Instead, we attach it to the hash and make it seem like the whole long thing is the password.

Many sites will suggest simply concatenating them together, $salt . $hash . However, I figure, with such a constant location, while the hacker does have to deal with random salts, he doesn't have to worry about the location of it.

So we take something that is constant with the user, but different enough to allow variations for storing the salt. I'll use simply the length of the password in plain text. If the password is 11 characters long, I insert the salt at character 11 of the hash. This way, it's different than a password that is 8 characters in length.

return substr($hash,0,$saltStart).$salt.substr($hash,$saltStart+1);

Now, this function you've been building up, all you need to do is add an optional argument for a hash. When a user tries to login, you look up the hash from the database, and supply their password attempt and hash to this function. Now check if the hash is supplied, and if so, calculate the position of the salt in the hash, grab the salt, and use that for your md5($salt.$hash) part. If the function returns a hash that equals the hash in the database, you have the correct password.

*I don't claim to be a cryptographer, so use at your own risk.

I'm personally not used to this database design, but I know plenty of people use it. When I work on projects that have this, I'm not particularly found of having to write:

$p = new Player;
echo $p->player_username;

I'd rather ditch the prepended part in all my PHP code.

echo $p->username;

Use Accessors

We can do this by writing some __get and __set functions:

public function __get($name) {
    $prepend = 'player_'.$name;
    if(isset($this->$prepend)) {
        return $this->$prepend;
    }
    return parent::__get($name);
}
public function __set($name, $value) {
    $prepend = 'player_'.$name;
    if(isset($this->$prepend)) {
        $this->$prepend = $value;
    } else {
        parent::__set($name, $value);
        //if no parent, you might want the default:
        //$this->$name = $value
    }
}

Basically, stated before, these get called when you try to access a property that doesn't exist on the object. So when we try to access username, we check if player_username exists, and if so, return that value.

MY_Model: Easily extendable

You could work this into a MY_Model class that extends Model, and then make all your models extend MY_Model. If you wanted to do this, I'd say make a property of MY_Model called 'prefix', and use prefix in the accesors. Then, in each sub-class, all you need to do is define the prefix.

class MY_Model extends Model {
    protected $prefix;
    public function __get($name) {
        $prepend = $this->prefix.$name;
        //...
    }   
}

class Player_Model extends MY_Model {
    protected $prefix = 'player_'; 
}

var a = ['one','b',3,false];
var b = a;
a[1] = 'BEEEE';
console.log(b[1]);

Reference, pointer, whatever

Caught on to what was happening there? We made one array, then assigned that array to another variable. That variable simply points at the same array, it's not copied. Now, when we change the array that's assigned a, we find the results of the change appearing b also.

This is because Javascript assigns complex types (notably Objects and Arrays (Functions and Strings count too, but they're immutable, so it doesn't matter)) by pointers. Usually called pass by reference, there might be some argument over the proper verbage. Ultimately, it doesn't matter much what you call it when you talk to yourself. It just matters that you understand what happens.

Making Distinct Copies

Now, sometimes, you may want a copy of the array or object instead of a reference, so if the original gets modified, your copy stays out of that sometimes confusing mess. There are a couply ways of copying an array or object, but what matters here, is that if one of the values is itself an array or object, you'll need to make a copy of that as well. Otherwise you'll get pointers in your facade of a copied object.

$unlink

The MooTools Core (1.2.2 as of writing) provides a function by the name of $unlink that solves this issue for us. Provide an array or object as an argument of $unlink, and it will return a copy that has been checked to make sure it has no back references. Let's do so to our original example.

var a = ['one','b',3,false];
var b = $unlink(a);
a[1] = 'BEEEE';
console.log(b[1]);

See? They're different. Go ahead and play with making arrays and objects that contain nested objects, and see what happens. Then you'll see the power that $unlink gives you.

When Things Were Right

When a form was built properly, I could easily understand what inputs a form had, and what input I had tabbed to. Quite simply, there were 2 tags the specifically improved the accessibility of the form for my screen reader: legend and label .

<fieldset>
    <legend>Personal</legend>
    ...
</fieldset>

When I tabbed to an input that was within a fieldset , and that fieldset had a legend , it would tell me. The above would read to me: "Personal grouping." So if this fieldset wrapped up inputs like your name, telephone, and e-mail address, it would remind me each time that this input was part of the "Personal grouping", so I knew I hadn't tabbed to a new fieldset . Good.

<label>
    <input name="personal:name" type="text" />
    <span>Name</span>
</label>

For specific inputs, having a label did exactly as we would hope. I tabbed to the input , and it read the label and input type: "Name, text." It specifically worked with the above example, when the input was inside a label . It would read the rest of the text inside the label .

When Things Sucked

I visited a few other sites that seemed to be using standards, and found that their forms performed far worse. It showed that using the correct structure for forms is actually very important . When a form used a simple paragraph before an input, with no label , guess what happened? Yep, it skipped it. When I tabbed to an input , it would just read me: "Text". Hey, great. Any text? You got it: poop.

Yea, not good.

Even worse

Even if someone managed to make up information for these fields, or perhaps, say they did have labels on them, one more form feature that screwed my experience using a screen reader: captcha . Some implementations simply had an image above the input, with no alt tag, no possible way for me to ever prove I'm a human being. Minus one call to action.

Try Out Your Own

I'd suggest grabbing NVDA , and surfing your site, and pay attention to your forms. See if the way you made them makes sense to a screen reader. And then visit some of your favorite sites, try out their forms, and compare with their markup. It's quite enlightening.

This leads to me to show the mark-up we use at Blazonco , which does work just fine with a screen reader, in another post soon.

Do any of you have any form accessibility tips beyond the basics? For example, how would you include some description text that isn't really the label (ex: Your password must be more than 6 characters.)

A Relatively Capable Browser

IE6, while certainly layout-challenged, can handle basic layout, and still decent color, background, type and image support.  People using Internet Explorer 6 are used to web pages looking decent.  Websites looking plain black and white with no design all of a sudden will make people think your site is broken (or just sucks).  And one principle of web standards is that they shouldn't think your website is broken .

Sure you could change the text colors, you say. But c'mon, its really not that bad to remove the problematic CSS from IE6.  Boagworld did a good job of showing how easy it is to do, and it still looks pretty decent.

The Standards Stance

I'll be the first to condemn IE6 to the farthest depths of the trash can. I hate the bugger.  But as a web developer, I also strongly believe in progressive enhancement , and giving each browser what it can handle.

Sometimes I'm asked to make something look the same in IE6 as Firefox 3, and while I do it (I need to eat), I strongly disagree with it.  My boss expects some whining from my side of the office when I'm told. I agree more with Yahoo's graded browser support .

The plain stylesheet to IE6 turns it into a cousin of Lynx, and certainly under-utilizes the power that IE6 does have.  Ultimately, it goes against the point of standards .  Why bother at all, if you aren't going to treat everyone the way they can.

I knew that inside a class function, this.constructor would reveal the function that makes new intances of that class. But that function is anonymous, so I couldn't ask for the Function.name property. But! But, if I have a value, I can check an object for the key of that value.

var Poop = new Class({
    get_class: function() {
        return $H(window).keyOf(this.constructor);
    }   
});

This made me super excited, cause now I can build an interface that uses the class name for a particular process. And when I decided to write about it, I figured I'd make sure this method worked in all cases. And realized a case where this wouldn't work: Drag.Move (Obj.Anything, actually).

Finding in Namespaces

The original function scans the window object for the class that has been declared. But what if you created the class inside some namespace? You could change the function to check the Hash of the namespace, but I didn't like that. So I pulled together a new Hash function that searchs a Hash recursively for a ke y (keyOf only goes one level).

Hash.implement({
    findKey: function(key) {  
        var val = this.keyOf(key);
        if(val) return val;
        for(var prop in this) {   
            if(this.hasOwnProperty(prop) && typeof this[prop] == 'object') {
                val = $H(this[prop]).findKey(key);
                if(val) {
                 return this.findKey(this[prop]) + '.' + val;
                }
            }
        }
    }   
});

A Class Extra

Now equipped with Hash.findKey, I altered the get_class function to work anywhere. This is a class that you can include in your Implements option for any new Class:

var GetClass = new Class({
    get_class: function() {
        return $H(window).keyOf(this.constructor);
    }   
});

With the Hash method, and this new class included in your scripts, this simple example works out:

var Foo = {};
Foo.Bar = new Class({ 
    Implements: [GetClass]
});
var a = new Foo.Bar();
a.get_class(); //returns 'Foo.Bar'

I'd love to hear any uses you might have for this in the comments .

3D Buttons

As a smaller example, I'll show the buttons I put together for the Blazonco admin post index page. Rather simple, but I wanted to achieve that effect you've seen in older buttons. You know, where the top part is light than the bottom, so it looks slightly raised out of the application. And then on hover, I swap the border colors, giving the look of being pushed in.

I threw a darker color on the bottom and right sides. The above picture shows normal (left) and hover (right). Of course, Print Screen hides the cursor (which I found weird). And here's the relevant CSS:

a.button {
	background-color:#fff;
	border-width:1px;
	border-style:solid;
	border-bottom-color:#aaa;
	border-right-color:#aaa;
	border-top-color:#ddd;
	border-left-color:#ddd;
	border-radius:3px;
	-moz-border-radius:3px;
	-webkit-border-radius:3px;
}

Having it in CSS allowed me to easily test out the results , and tweak the color slightly as I decided one side was too dark or too light. And I also was able to easily experiment with how round I wanted the button. When using images for all this, you'd have to make the changes in Photoshop, and save it and upload it again. So a major gain is in how easy it is to maintain .

Shadows

I had the joy of turning a comp with mutliple rounded corner boxes and shadows and the like into a working web-site not long ago. I originally thought that these boxes would also need to be expandable, and I wondered how to achieve this in a feasible way. I settled on using various CSS3 techniques instead of image slices with sliding door techniques.

The end result was as such:

In the boxes, I used a gradiant slice for the background, and then used only border and border-radius to obtain a kind of 3D look. Here's the CSS:

.module {
	background:#fcfcfc url('images/module.png') repeat-x left bottom;
	border:1px solid #ccc;
	border-bottom:2px solid #bbb;
	border-top:1px solid #ddd;
	border-radius:10px;
	-webkit-border-radius:10px;
	-moz-border-radius:10px;
}

By making the border bigger and darker on the bottom, and lighter and thinner on the sides and top, I gave it a pseudo-shadow. The benefits of this over an image is that it only took 1 element to style (the div), and it could easily expand in any direction without running out of image.

Since it was using CSS3 techniques, it was squared in Internet Explorer, but continued to look good. This is an important factor of progressive enchancement , since I made sure to use CSS that looked nice in older browsers.

CSS Feature Detection?

One last rule I would have liked to add but never did was using Safari's drop shadow property. That would have achieved an even nicer looking shadow in Safari. The reason holding me back, was that I'd already used border's to accomplish this effect, and didn't want to try to remove them for Safari. This would have required some Safari CSS hacks, since I currently don't know of a way to do CSS feature detection.

It'd be cool if you could do something as such (I'm going to steal some Javascript syntax):

if(-webkit-box-shadow) {
	.module {
		border:none;
		-webkit-box-shadow:5px 2px 2px #bbb;
	}
}

Do any of you have any suggestions on how to properly achieve that with current technologies? And I'm not interested in server-side sniffing. That's obvious, and sub-optimal.

if (params instanceof Function) params = {initialize: params};

If you only pass in a function , instead of an Object with functions in it, then that function will be the initialize (or constructor) of your class.

So instead of:

var Test = new Class({
    initialize:function() {
        console.log('testing');
    }
});

you can now write:

var Test = new Class(function() {
    console.log('test');
});

I'm not quite sure of a good use for this, but if you just needed a quickie class that you just want to instantiate and that's it, then this is for you!