Custom Dropdown

The functionality of our drop-down will mimic that of a regular dropdown box with one exception. Since we can not style the scrollbar, our drop-down will never display one. Instead, it will just keep expanding as you add new links.

HTML
To start off with, our select needs a few different elements to work properly. First off, we need a container that will hold our select. We will also require a list of elements that we want to appear when you click the drop-down. Finally, we need a default element to hold the current selected item and an arrow to signify that we can click on it to display more options. I’ve assigned the classes and Id’s to the elements as necessary. clair-select-active is the default item that will be displayed as well as what is displayed when an element is clicked on.

<div class="clair-select-container">
  <div class="clair-select">
    <div id="clair-select-active">Where My.Feet Have Been</div>
    <ul class="clair-select-links">
      <li><a href="#">Nookish</a></li>
      <li><a href="#">Orange Pine Co</a></li>
      <li><a href="#">Where My.Feet Have Been</a></li>
      <li><a href="#">Your Website</a></li>
    </ul>
  </div>
</div>

CSS
Before we get to the clair specific styles, these are the default ones applied to the entire page:

body{
  font-family: Arial, sans-serif; 
  font-weight: normal;
  font-size: 14pt; 
  background-image: url('bg.png'); 
  margin: 0px;
}
a {
  color: #CCC;
  font-weight: bold;
  text-decoration: none;
}

The first style we get is the clair-select and the clair-select-container These style our entire select container.

.clair-select-container{
  position: relative;
  padding: 10px 0px;
  margin: 0px 0px 40px;
}
.clair-select {
  background-color: #000; 
  color: #CCC;
  -moz-border-radius: 12px;
  -webkit-border-radius: 12px;
  -o-border-radius: 12px;
  -khtml-border-radius: 12px;
  border-radius: 12px;
  padding: 10px 12px 5px;
  font-size: 14px;
  display: inline-block;
  border: solid #555; 
  border-width: 1px 0px 0px 1px;
  width: 230px;
  -moz-box-sizing: border-box;
  box-sizing: border-box;
  opacity: 0.7;
  filter: alpha(opacity = 70);
  position: absolute;
  z-index: 2;
}

The purpose of clair-select-container is to make sure when we expand our select dropdown it doesn’t push elements out of the way. Instead of floats nicely above them, and our slight opacity setting will display a faint outline of what it’s coverting.

There is a lot of vendor specific styling going on in clair-select, but the only one that I think warrants explanation is box-sizing and filter.

• box-sizing: is a CSS3 spec that allows us to change the way that the browser interprets the “box-model” I’ll have to do another post to fully explain the box-model, but essentially it is the difference between including padding and border sizes within the “width” element, or adding it on afterwards. This forces Firefox to render the box-model the way Internet Explorer would ¹.
• filter: is a Microsoft proprietary spec that allows us to use a number of IE only effects. The particular effect I am utilizing is alpha-blending which allows us to change the opacity of the element. I’ve turned the opacity done just a little so that things are still readable, while allowing us to see the background. This has the added benefit of a neat visual effect whereby it looks like our element is slightly inset.

The next style we’re going to add is that of the active element. All we do here is add the arrow as a background image and position it to appear on the right side of the element.

#clair-select-active{
  background-image: url('down.png'); 
  background-repeat: no-repeat;
  background-position: right;
}

Finally, we’re going to style all the links. Nothing too fancy here. We’re just getting rid of bullets, spacing everything out a little and treating the anchor tags as block elements within our li’s.

.clair-select-links {
  margin: 0px; 
  padding: 5px 0px 0px;
  display: none;
}
.clair-select-links li{
  list-style: none;
  padding: 1px;
  margin: 0px;
  overflow: hidden;
}
.clair-select-links li a{
  font-weight: normal; 
  display: block;
  padding: 5px;
  margin: 0px;
}
.clair-select-links li a:hover{
  background-color: #282828;
  -moz-border-radius: 8px;
  -webkit-border-radius: 8px;
  -o-border-radius: 8px;
  -khtml-border-radius: 8px;
  border-radius: 8px;
  color: #DDD;
}

JavaScript
To add functionality to our drop-down we need a bit of JavaScript. I’m utilizing jQuery, but your own JavaScript library should have similar functions. We need to add two kinds of functionality.

1. We need to switch between minimized and maximized states whenever a user clicks on the clair-select-active element.
2. We need to switch to minimized and populate clair-select-active with the text from the menu item

$(document).ready(function(e) {
  // This is just for cross-browser prettiness
  $('#clair-select-active').css('cursor','pointer');
 
  // This will toggle everything as necessary
  $('#clair-select-active').click(function(e) {
    if($('.clair-select-links').css('display') == 'block') {
      $('.clair-select-links').slideUp(); 
    }
    else {
      $('.clair-select-links').slideDown();
    }
  });
 
  // This will populate clair-select-active with whatever you click on
  $('.clair-select-links a').click(function(e) {
    e.preventDefault(); 
    $('#clair-select-active').html($(this).html()); 
    $('.clair-select-links').slideUp(); 
  });
});

And that’s it, you’ve built a custom select drop-down. With a little JavaScript trickery, we can even go so far as to include it within forms. We’d just need a hidden form element and then when we populate clair-select-active we would also populate the value attribute of our form element.

This solution works in the following scenarios:

• IE 7+
• Firefox 3.5+
• Chrome 3+
• Opera 10+

You can download all the files used in this tutorial here: Custom Select Files

In web development, every page will have it’s own Model, View and Controller. This is to ensure that only the information you are requesting is loaded. A lot of those new to the MVC approach will attempt to create a master controller which will then delegate this information to each Model as requested. In MVC, this approach doesn’t quite work. By creating separate entities for each requested page you will find that not only is it easier to maintain and update, but that MVC isn’t that hard to understand at all.

The Big Picture
The easiest way to understand MVC is to step back and look at the whole picture in terms of real-life. In this example, our Controller is going to be the Librarian, the Model is going to be the Library Catalogue and the View is going to be a Book. A user will come up to the Librarian and say “Hey, do you have Book XYZ?” The Librarian of course has no idea. It’s not their job to know where each Book is, but simply to know where to find the information that you are requesting. Regardless of what you are requesting the Librarian will look through a Library Catalogue, but they may look in different kinds of Catalogues. For example, if you say “Hey, do you have the Horror Book XYZ?” they can ignore every other category except Horror. Likewise if you say “Hey, do you have the Romance Book XYZ?” they can ignore every other category except Romance.

The Pieces of the Puzzle – The Controller
The Controller the is the primary building block of an MVC system. Everything you build is managed by the Controller (it Controls see? Programmers love these little word games). The Controller figures out what the user is trying to do and accordingly it goes through the appropriate Model and returns those results to the appropriate View. You can think of the Controller as a messenger. Basically when the user visits a page they are saying “I would like to see the [Gallery] page”. The Gallery Controller will see this and go right over to the GalleryModel and say “The user has requested this information”. It then waits for GalleryModel to respond, and then it takes those results and runs over to GalleryView and goes “Pretty this up”. It then shows you the prettied-up version.

The Model
The Model is also known as your Data Manipulation layer. This should contain functions that interface with the database. Insertion, Updating and Deletion should all occur here, with the results of each passed back to the caller. This centralizes all your DB calls to a single file for a single controller. In this way you know that modifying your “Gallery” table means only modifying your GalleryModel and GalleryView. It doesn’t seem like a big issue to inter-twine your database manipulation and controller at this stage simply because it isn’t. Of course you can integrate your Model directly with the Controller, but by segmenting these you can ensure a much easier re-use of code. Think about it this way – a gallery model can be copied and modified a little to turn it into a blog model. Since the Model doesn’t care about what to DO with the fields, you just need to update what fields it SHOULD be dealing with.

The View
The View is the easiest piece to explain. It simply acts as a display mechanism. It accepts some values from the Controller, mixes it with HTML and spits the result back to the controller. Think of it is a node-based theme engine. For example, you could have a function in your GalleryView that just accepted the URL of a thumbnail and added some HTML which, when styled, made it resemble a Polariod. At a later point in time, if you want to change this, modifying this single function will ensure that everything is changed uniformly.

The Big Picture – Now with the right words
So now we can revisit our Librarian and ask for a new book. We ask the LibraryController for “Horror book XYZ”. The LibraryController invokes the LibraryModel and executes the findBook() function passing it the genre (horror) and book name (XYZ). The LibraryModel executes a quick Database Query to figure out the results. Just so happens there are 5 books in that genre that contain XYZ (XYZ, WXYZ, AXYZ, XYZZ, XXYZ). It passes the result set BACK to LibraryController. LibraryControlled takes the result set and invokes LibraryView, calling the formatBookList() function using the result set as the argument. formatBookList() adds some HTML mockup to each entry and makes everything look good and then passes the HTML back to LibraryController. LibraryController shows you the result.

Variations
Some descriptions of MVC will modify it so that the Controller ignores the view and instead the Model is what passes the data to the View. Either way still conforms with MVC standards, which really just involve separting everything.

Advanced Concepts

Routers
When dealing with server-side languages on the web we have to remember that things don’t work the same as in a desktop environment. Event-driven programming may work fine for C# and Java, but doesn’t work the same way for PHP. In PHP, our equivalent fo Event-driven programming would be URL-based programming. An “event” as far as PHP is concerned, is the user trying to visit a page. This page should trigger some kind of action. In most MVC frameworks (all I would think), you get something called a “Router”. This Router class is essentially a way of registering URLS to certain Controllers. For example visiting www.example.com/gallery/view/48 would cause the Router (or page that invokes the Router) to invoke the GalleryController and make a call to the view() function passing it 48 as an argument. In this way they abstract away explicitly invoking galleryies and can have a single index.php page which invokes the Router and makes the calls as necessary.

Multiple Inheritance
While PHP doesn’t allow for Multiple inheritance (ie GalleryController extends c1, c2, c3) it does allow for cascading inheritance (GalleryController extends c3; c3 extends c2; c2 extends c1; and now GalleryController can do everything c1, c2 and c3 can). Because of this we can actually speed up our Model/Controller creation by extending a singple base Model or Controller class. These classes would ideally have common functions that all Models or Controllers could potentially need at some point. One example would be to force all Models to inherit from BaseModel which could be a custom created Database Manipulation functions that all Models would need.

Once you begin researching you’ll notice that while a lot of browser-based text games take into account Collision detection, they seem to be missing Aggro detection. Aggro stands for either aggravation or aggression and is essentially a way to tell if a monster will attack you or not.. As you’ve probably noticed some monsters tend to rush at you from across the map, while others seem to completely ignore you until you attack them. This is Aggro.

One of the easiest ways to detect aggro is to simply add a variable to your monsters to signify “sight”. This sight variable will dictate how far away you need to be before a monster will attack you. Set this to 100 to have a monster rush at you from across your map or set it to 0 so that it will never attack unless you attack first.

Detection aggro is as simple as following two formula’s. The first will be to figure out the distance between you and the monster and the second will simply be a quick check to see if you fall within the monsters aggro radius. To start off, you need to grab the jQuery javascript framework. While you CAN do this from scratch, jQuery lets you do it a lot easier, plus you can probably add a bit more jazz to your current game if you’re not already using it. If you’re unsure of how jQuery works, take a look at our quick intro to jQuery or just check out the jQuery documentation. Now just cobble together a quick webpage and include the jQuery library. I’m using the minified version 1.3.2 of jQuery, so if you’re not using the same one, make sure you replace that line.

<html>
<head>
	<title>Collision Detection</title>
	<style type="text/css">
	table#grid{
		border-style: solid; 
		border-width: 0px 1px 1px 0px; 
		border-color: #CCC; 
		padding: 0px;
	}
	table#grid tr th{
		border-style: solid; 
		border-width: 1px 0px 0px 1px; 
		border-color: #CCC; 
		text-align: center; 
		color: #333; 
		font-size: 0.7em; 
		font-weight: bold; 
		font-family: "Arial";
		background-color: #EDEDED;
	}
	table#grid tr th.run{
		width: 12px;
	}
	table#grid tr td{
		width: 50px; 
		height: 50px; 
		border-style: solid; 
		border-width: 1px 0px 0px 1px; 
		border-color: #CCC; 
		text-align: center; 
		color: #E0E0E0; 
		font-size: 0.7em; 
		font-weight: normal; 
		font-family: "Arial";
	}
	table#grid tr td:hover{
		color: #333;
		background-color: #F3F3F3;	
	}
	.player{
		background-color: #333; 
	}
	.monsterA{
		color: #333; 
		background-color: #AA0000;
	}
	div#debug{
		border-style: solid; 
		border-color: #333; 
		border-width: 1px; 
		float: right; 
		border-color: #EDEDED;
		text-align: left; 
		color: #333; 
		font-size: 0.9em; 
		font-weight: normal; 
		font-family: "Arial";
		width: 300px; 
		padding: 10px;
	}
	.monsterN{
		background-color: #00AA00;
	}
	</style>
	<script type="text/javascript" src="jquery-1.3.2.min.js"></script>
</head>
<body>
 
</body>
</html>

You’ll notice a bunch of CSS in there, but you can ignore that. It’s pretty straight forward and really it’s just meant to pretty things up a little. Now we’re going to add a quick grid so that you can get an easy visual representation of where you are and where your monsters are and if they will aggro or not. You can copy and paste the following line a few times, and change the y coordinate (x,y) to match which row you’re on.

<tr>
	<td>0,1</td><td>1,1</td><td>2,1</td><td>3,1</td><td>4,1</td><td>5,1</td><td>6,1</td><td>7,1</td><td>8,1</td><td>9,1</td>
</tr>

Finally, I’ve just added a “debug” section, so you can get a textual representation of what’s going on. It’s just a div placed above the grid.

<div id="debug">
	<b>Debug</b><br><br>
</div>

The Code
Now for the code that will give us a visual representation of our player and our monsters. First off we are going to initiate a few variables that we will be using throughout our script. They’re pretty self explanatory.

var playerPlaced = false; 
var monster = []; 
var player = [];

Now we’re going to set it up so that when we click a square it will check if our player is already placed or not. If he is NOT placed, then we are going to place him and update our “debug” section.

$('#grid tr td').click(function(){
	var distance;
});

if(!playerPlaced){
	player['loc'] = $(this).html().split(','); 
	player['sight'] = 0; 
	$(this).html('@'); 
	$(this).addClass('player'); 
	playerPlaced = true; 
	$('#debug').append('Player: '+player['loc']+'<br>');
}

Notice that we’ve set player['sight'] to 0. Why? Simply because your player doesn’t have an aggro radius. He may or may not attack at your discretion, so it’s irrelevant. A monster however, will ALWAYS attack if you get within its aggro radius (assuming no other modifiers).

The next bit will just place our monsters if there is already a player on the field. When we do, however, we are going to call some functions that will take care of calculating distance and checking if the monster will aggro. We’ll go over those first, since they’re more complicated.

Distance
To calculate the distance of two points we are simply going to take the x,y coordinates of both our monster and player and perform some math on them. The formula that we will be using is actually the distance formula between two points (and you wondered when you would ever use it…) and something that’s been drilled into us in every math class. The formula itself is a basically sqrt(sq(x1-x2)+sq(y1-y2)) so translating that to our game code it will look more like

sqrt(sq(player[x]-monster[x])+sq(player[y]-monster[y]))

The squaring and square rooting would take us a lot more work, if JavaScript didn’t already have those built in! Our actual distance formula in JavaScript (after being placed in a function) will look like this:

function getDistance(from,to){
	distance = Math.floor(Math.sqrt(Math.pow((from[0]-to[0]),2) + Math.pow((from[1]-to[1]),2))); 
	return distance; 
}

Intersection
Basically intersection in our scenario will take a look at the player and see if he falls within the aggro radius of the monster. It’s a very simple check that just goes if (distance < aggroRad) then it will aggro.

function willAggro(aggro,distance){
	if(distance > aggro){
		return false; 
	}
	else{
		return true;
	}
}

Monster Insertion
Finally, we’re going to do our check to see if a monster will aggro a player or not depending on its distance to the player.

monster['loc'] = $(this).html().split(','); 
monster['sight'] = 1; 
$(this).html('X');
 
distance = getDistance(player['loc'],monster['loc']); 
if(willAggro(monster['sight'],distance)){
	$(this).addClass('monsterA');
}
else{
	$(this).addClass('monsterN');
}
$('#debug').append('<b>Monster:</b> '+monster['loc']); 
$('#debug').append(' <b>Distance:</b> '+distance+''); 
$('#debug').append(' <b>Aggro:</b> '+willAggro(monster['sight'],distance)+'<br>');

And that’s all there is to it. If you run this page and take a look, you’ll notice that clicking a grid will place your player and clicking anywhere else will cause the monsters to appear in either green (if too far away to aggro) or red (if it will aggro). This is also noted in the debug section!

Here is our completed javascript section

$(document).ready(function(){
	var playerPlaced = false; 
	var monster = []; 
	var player = [];
 
	$('#grid tr td').click(function(){
		var distance;
		if(!playerPlaced){
			player['loc'] = $(this).html().split(','); 
			player['sight'] = 0; 
			$(this).html('@'); 
			$(this).addClass('player'); 
			playerPlaced = true; 
			$('#debug').append('Player: '+player['loc']+'<br>');
		}
		else{
			monster['loc'] = $(this).html().split(','); 
			monster['sight'] = 1; 
			$(this).html('X');
 
			distance = getDistance(player['loc'],monster['loc']); 
			if(willAggro(monster['sight'],distance)){
				$(this).addClass('monsterA');
			}
			else{
				$(this).addClass('monsterN');
			}
			$('#debug').append('<b>Monster:</b> '+monster['loc']); 
			$('#debug').append(' <b>Distance:</b> '+distance+''); 
			$('#debug').append(' <b>Aggro:</b> '+willAggro(monster['sight'],distance)+'<br>'); 
		}
	}); 
}); 
 
 
function getDistance(from,to){
	distance = Math.floor(Math.sqrt(Math.pow((from[0]-to[0]),2) + Math.pow((from[1]-to[1]),2))); 
	return distance; 
}	
 
function willAggro(aggro,distance){
	if(distance > aggro){
		return false; 
	}
	else{
		return true;
	}
}

This is a very simple way to check aggro and the reason I placed it in its own function was incase you needed to modify it in any way (for example if a monster was under 10 levels its aggro would be 0 always). 

Anyways, what I’m actually talking about today is Object Oriented Programming. To many it’s a very confusing concept and they’re flooded with questions such as when to use it, why would I use it, what IS it? And to others it comes as easy as breathing.

*NOTE* OOP is a slightly advanced concept. While you should try and learn it as soon as possible, you should have at least a moderate grasp of classes and functions.

What is it?
OOP is a way of programming that breaks down an object into pieces. Essentially an object would be something that you’re trying to achieve. OOP breaks this down so that you don’t have to continually write the same code. Instead, you can just copy over the class file, and then use the same functions as you normally would. That is the bonus of OOP.
To think of it another way, imagine a robot. That robot is what we are trying to build. But a robot is made of different pieces right? 2 arms, 2 feet, a body and a head. In Object Oriented Programming, you would take each piece and make it it’s own class.

How does it work?
What we would essentially do now, is populate this class with things that the arm can do. In this example, lets just make it very simple. All the arm can do is Judo chop and Punch. To accomplish this, all we would need to do is create two functions within our class. However, note that I said we have TWO arms. We would need some way of differentiating the right arm from the left right? The easiest way to do this, is to create a “constructor” function that would accept the name of the arm and store it for access later on.

name = $name;
 }
 
 function punch()
 {
   echo $this->name.' punches';
 }
 
 function chop()
 {
   echo $this->name.' judo chops';
 }
}
?>

From that piece of code alone, we can actually create as many arms as we need. And that is the beauty of OOP. Now my robot can run on the same piece of code, regardless if it has 2 arms, or 50 arms. Imagine, an awesome 50 armed robot running off no extra code?

When would you use it?
As often as it makes sense. If you’re building any application, your best bet would be OOP. However, if you’re working on something like a website, there really isn’t a need for it. You’ll find people from all over the internet who say that you should use OOP all the time, and others who claim that it is the worst thing to happen to programming. Ignore them. In the end, it’s up to you to decide when you need to use OOP. If you find that you seem to be using a same bit of code all the time, wrap it in a function. If you find a group of functions you use all the time, and they’re related, wrap it in a class. If you have a group of classes you use all the time, wrap it in a framework.

Picture by toasty http://flickr.com/photos/toasty/

Two days in and I’m already breaking from routine. But this is something that I just have to post. It isn’t necessarily a big deal, and it’s something that has been going on for a quite some time, but I would just like to prove how easy this actually is.

Trout or Salmon?
Neither. We’re going after sucker fish. The ones who know enough about computers to do their banking online, but not enough to question the incorrect SSL certificate. They think they know enough about computers to make them invulnerable to anything, which is why phishing attempts work so well.

The Concept
There are numerous ways to go about phishing scams. The easiest of which involves just copying the code from the actual website. But we run into issues. The most basic of these is that if we keep the current code, and if the website uses relative links to their images, we’re screwed. We have to either replicate their directory structure, or hope to hotlink the images. Of course, a little .htaccess hack, and anyone linking to any images on the server that isn’t FROM the server, can easily be blocked. Sure it would work, but we’re lazy people right? We need the quickest solution. And the quickest solution, is an IFrame.

Essentially we are going to include the website we want in an IFrame and absolute position the input/submit form elements over the ones that are already present on the page. If that sounds like a load of BS to you, then attempting this is out of your league. If it doesn’t, you’ve probably already thought about this before and just never got around to it.

K.I.S.S – Keep It Simple Stupid
The beauty of this code is that it can be accomplished in essentially under 7 lines. As a bonus, if the user is really foiled into entering their information, you can easily redirect them back to the website they were trying to access. To them, it will seem as if they just entered the information incorrectly and they will proceed to do it again without questioning. After all, who things that they would be the subject of a scam like this?

Here is a brief overview of the code without the pixel perfect placements:

<form action="catcher.php">
<input name="username" type="text" />
<input name="password" type="password" />
<input style="dispay: none;" type="submit" />
</form>
<iframe name="myframe" src="yoursite.htm" width="100%" height="800"></iframe>

It’s a very simple solution. Now once you’ve included the website that you want, it’s really just a matter of adjusting the size and placement of the input boxes with CSS. Then, if you’ll notice, I turned the submit button invisible. What we are going to do is actually place that button over top of the actual submit button on the website. This way, the user thinks that they are clicking on the submit button, but in reality they are clicking on our invisible button.

When to use it?

1. The user is stupid. They won’t notice the slight url change (ideally you will purchase a domain name resembling the name of the website you wish to spoof)
2. The login form is present near the top of the website you are visiting. This is important, as if it’s located somewhere else, when you absolute position your login elements they will float above nothing and the user will be suspicious.
3. You won’t be breaking any laws. This one is really a disclaimer. I don’t expect readers to run out and do this, this is more of a proof of concept hack that I’m sharing.

What can they do about it?

1. Not a whole lot. If the user has javascript enabled then the website simply has to add a bit of code to their page that will break it out of the iFrame. A lot of websites already do this, but most don’t (for whatever reason).
2. If a user has Java Script disabled then they’re out of luck. The website can’t do a damn thing to break out of it.
3. Pretty much impossible to detect. Sure a shrewd admin can backtrace the IP through the log files, but they wouldn’t have a reason to.

Not Bait and Switch

Bait and Tackle
Of course, a hack like this is wholly incomplete. What would be necessary would be something like an auto-redirect or a url masker installed on the users computer. Then whenever they accessed a website of your choosing, they would automatically be directed to your website. The bonus of something like that is that no matter what happens, you can pretty much guarantee that they’ll end up at your site for you to start your phishing.

End Note
Don’t mistake my incompleteness for inaccuracy. For those who would actually seek to use this information for actual phishing scams, a few important pieces of information were removed, such as how to hide form elements (and numerous others). Those who are actually looking to learn from this should know a few other things that could make this idea more complete. If there is enough interest, I may put up answers to a few questions, such as how to not have to copy their entire website.