I am constantly asked by desktop developers how to make the transition to web development. Web applications are almost as powerful and as fast as desktop applications these days. There are no installation hassles as web applications reside in just one place: on your server. The user simply navigates to their application's starting point on their browser and can immediately start working. In this blog post, I provide you with guidance on how experienced developers can get started with web programming. I am not going to go in-depth into each technology and tool. Instead, I will introduce you to terms, technologies, and tools needed for web development, and provide you with links on where you can learn more about each.
As more and more users interact with web applications on their mobile devices, it is becoming increasingly important for us to allow them to work offline. There are many cases where users need to work offline, such as on an airplane, in a remote location where there is no cellular access, or perhaps on board a large ship where Wi-Fi is not available. If you can store data local to your web application, the user can continue to work even without a connection.
When a user clicks on a button on a web page, there can be a delay between posting back to the server and the next action that happens on the screen. The problem with this delay is the user may not know they actually clicked on the button and tries to hit the button again. It is important to give immediate feedback to the user so they know that the application is doing something. This post will show you how to disable the button, display a pop-up message and gray out the background before the post back happens thereby providing feedback to our user.
What's the problem that I'm trying to solve?
In my current project, I have a set of Enums on my server that represent certain lookup data. For example, I have a PhoneType and AddressType Enums that I use instead of using the specific integer that is used in the database. This makes the code more readable and there aren't a bunch of "magic ints" (tm/patent pending) thrown around throughout the code. This is a fairly standard practice.
Two developers. One Backbone tutorial. One of us is an avid hockey fan. The other is a bit of a sci-fi/fantasy nerd. Therefore, it only makes sense that the app we'll be building is a fantasy hockey league website during this tutorial series. Because seriously - who doesn't want to see Darth Vader vs. Sauron on the ice? An epic seven game series of elves of Lothlorien vs. stormtroopers of the Death Star? Yes, please. I'm sure there's a "one puck to rule them all" joke in here somewhere. I'll leave that exercise to you, dear reader.
Our heroes have fought their way through the Death Star's fighter screen and can see the trench. As they enter the trench our pilots stabilize their deflector shields, preparing for the torrent of incoming turbolaser fire that will no doubt be coming their way.
In this post, we'll take a look at adding some validation rules to our
Pilot models. Hopefully, this effort will prevent our users from... err... having their way with our meek and rather naive Starfighter Recognition Guide. Our exhaust port is small, it'd be a shame to see it damaged by some ham-fisted users.
In our last post we walked away with a fully-functioning Starfighter Recognition Guide that could save a
Ship and any changes (create/update/delete) to its associated
Pilots. Neat, right?
Before we run off and save everything willy-nilly, we should probably go about checking to make sure our users provided the data we need. Let's add some data entry requirements to our application, shall we? Here's what we need to do:
Shipmust have a name.
Ship's name must be between 3 and 50 characters.
Shipmust have a crew.
Shipmust have between 1 and 5 crew members.
- Arbitrary? Sure. But I figure if a
Shiphas more than 5 crew members, it's probably a capital ship or on a scale that isn't appropriate for a Starfighter Recognition Guide.
- Arbitrary? Sure. But I figure if a
Shipmust have a speed.
Ship's speed must be between 50 and 200... err... thingies per... umm... unit of time.
- At the risk of having my Star Wars nerd card revoked, I'm not sure how the speed of a starfighter is measured. Yes, I looked it up. Nope, I couldn't find anything conclusive.
When we last left our heroes, they fought their way through the superstructure of our application and were setting up to finish it off. Having defeated the TIE fighter screen, our intrepid fighter pilots have descended into the trench of the Starfighter Recognition Guide. Their computers are locked, they're getting a signal...
Stabilize your rear deflectors and watch for enemy fighters - there's gonna be a tubolaser battery's worth of code in this one.