Sitting in front of a computer all day long can get boring. Sure, I love what I do. But after staring at text for a while, you have to break it up! And many developers have toys on their desk for just this reason. Mine's a Rubik's Cube.
Quite a while ago, I released a simple-to-use MooTools tabs class, and it continues to be one of the most frequented posts on the site. With so many people obviously desiring a MooTools tabs plugin, I've added a few new features to the plugin, as well as moved it to Github for inclusion in the future MooTools Forge.
I just wanted to document this rather frustrating bug here, so I can look it up later, and hopefully help anyone else who is running into something similar. This bug involves select tags, specifically setting their innerHTML property.
I had a list of options to give to the user, and a select box would work perfectly. Since DOM methods have burned me in the past, I felt innerHTML was the safer route. It appears, that they both have safety curves like a sine and cosine graph.
We built a Store Locator for our Content Management System, and needed to calculate what stores were close by. That's simple enough in PostgreSQL, which a Point unit type, and simple trigonometry. However, in the Admin area, where you can add new stores, I needed to accept an address in its normal format, and convert that in to longitude and latitude points to be stored. Google's Geocoding API helps us do that.
One of my favorite methods that I use constantly in various interfaces combines fading and removing of an element. It could be a table row, or list item, or a div, but often times when I wanted to remove something, I'd like it to remove with a fade. And not always wanting to write to listen for the complete event and then remove the element. So I'll show the original I use in Prototype, and then a port to MooTools.
Dates are a peculiar type of data that we have to work with. In some sense, they aren't a number, but instead are a combination of month, day, and year. But at the same time, in most programming languages, they are fundamentally a number: the number of seconds since the Unix epoch.
In our heads, it's quite easy to do Date math. Moving forward a week requires just adding 7 days. How would you do that with a Javascript Date? Programming languages usually try to make working with Dates as logical as it is to do in our heads. So I a little surprised at an irregularity in using Dates in my math.
As I work on an internal time tracker for our company, I needed to show all the TimeEntries for a specified week. To specify which week, it made sense to simply select 1 day in the week, since that's the easiest default control in Flex. This let's me get Sunday and Saturday, the start and end of the week, so I can build a query that grabs entries between those 2 dates.
In two languages that I use often (PHP and Javascript), there's 2 different equality operators when comparing values. It's become quite common to see places expressly tell you that you should only ever use one of them. That the other is evil. People see this, and then point fingers whenever you use 2 equal signs instead of 3. Here's perfectly valid reasons to use equal operator (==) instead of identity(===).
I've talked previously about getting private variables and methods in your classes , but doing so was always kind of hacky. In Javascript, elements don't have a native way to hide properties. So we have to come up with creative ways like using closures . In MooTools 1.2.3, we have a way to protect class methods.
Web development has become increasingly popular. Does that make it easy? Does that make us dumb?
Certainly, as Michael Braude says, the barrier to web development is incredibly low. HTML can be learned in a couple hours. A couple more and you can make something "just work" in Javascript. As a web programmer, I never have to worry about 3D rendering, rarely do I ever have to care about threading, writing to disk is taken care of for me by SQL. The problems we're trying to solve usually aren't so astronomical to need an ingenious algorithm designed.
MooTools lets you listen to events from 2 mediums: Elements and Classes. From classes, you can fire any event you want, and listen for it elsewhere. But with Elements, events are usually tied towards native DOM events. MooTools gives you the ability to define custom events for elements, by adding an entry to Element.Events .
With this in mind, we will consolidate the process of keeping track of one-time events in our custom event.
As I continue to flesh out my MooTools MVC framework, I found a neat way to implement a templating system, using only what MooTools gives me. The goal of templating systems is to allow you to write in your target format (usually HTML), and denote where variables should be tied in.
var example = 'My name is {name}. I love {passion}';...
Batch programming is certainly very easy to understand and write. You order a todo list and give it to the compiler/interpreter. It's what's usually taught first when you learn to program, and even in some server-side languages, you batch program (PHP doesn't have events at all, for instance). However, persitance applications that live on the desktop (and perhaps Ajax applications with minimal page refreshes) rely on event-driven programming. You set up a user interface, and then wait for the user to do something to that interface, and then respond to the event.
This is all well and great. But I've hit a problem a couple times recently as I create more desktop applications. I thought this would be easy to find, since I've hit the problem often and early. But I haven't, so I'll have to solve it myself. Sometimes, a component might have a one-time event that you need to listen to, and you don't know if that event has fired or not.
I've been twitting... tweeting... using Twitter for, oh, a little while now. I can't actually remember, maybe since the beginning of the year. And I've never really let anyone know, other then putting my latest tweet on the right side of my web-site.
In Javascript, the this keyword can be a tricky thing. It's trickiness comes from how functions behave differently depending on how you call them. What? You can call them differently? Yep! There's 4 major invocation patterns for a function, so let's see how each works, and how they handle this.
- Method Invocation
- Function Invocation
- Constructor Invocation
- Apply Invocation
