Problems with Web Programming
Many programmers, even those with years of experience run into a problem when it comes time to develop for the web. Web programming just seems to throw them completely and causes extreme panic and irritability. There are reasons for this, but you can overcome it without too much trouble.
I've seen this for years now. Not only have I done web development for quite a few years, I also work with Computer Science students who must occasionally create a web-based project. If you can get people calmed down and start listening to the solution, they usually get it.
The main cause of the problem is that the budding web programmer looks at the whole project all at once rather than breaking it into its different parts. By seeing the server-side code, the database, and the HTML as one big morass, it is a frightening, tentacled beast. Once you divide the project, the individual parts are tamable.
Model View Controller
In programming, we refer to the Model View Controller concept. In simplistic terms, the Model is the data or information with which we are working, the View is the presentation of the info to the user, and the Controller is the program logic that does the work. In web development, the Controller is the server-side program, the Model is from a database and some server-side code, and the View is the web page that we send to the user's browser.
What about Servers?
You may wonder where the web server fits into this. From the point of view of the web developer, we can pretend that the web server is the host machine and operating system on which our code is running. Again, we are pretending this to keep things simple. The server provides our inputs and outputs (I/O), and runs our code through use of a plug-in for our language.
HTML is a Document
Generating HTML really seems to present a problem. For those who don't know, HTML (Hyper Text Markup Language) is the document that tells your browser the information to display and how to display it. It uses special formatting commands, called "tags", to tell the browser how to draw your content.
The web programmer generates these HTML documents in the same they generate text documents for files or printing. There really is no functional difference in document generation. The only difference is that the HTML document contains the tags and the text file probably contains tab, line feed, or form feed characters.
In the same way, sending the HTML document to the browser is no different than sending a text file to the printer. Once you send it, you are done with it; there can be no more changes. The sent HTML document is stateless, that is, you cannot change anything about it. (Note: there are ways to change the state of an HTML document with client-side code, described later, but the stateless thing is important for the server-side coder.)
We handle the appearance of HTML pages through Cascading Style Sheets (CSS) and this is a real pain. Browsers all work with CSS differently and that adds huge amounts of frustration to the web developer's work. Overcoming this requires experience and expertise. For the new coder, try not to worry about the frustration. Work on a functional web project first and worry about the pretty part later. If you can, try to get assistance from an experienced style sheet artist.
Aren't Forms Interactive?
Web forms provide a mechanism by which the user can enter data and then send it to the web server for processing. That would seem to contradict the idea of being finished with an HTML document once we send it. In reality, it does not.
For coders used to working with a GUI on a desktop machine, the GUI code is part of the overall program and there is a constant connection between the Controller and the View. It looks like a web page with a form is doing the same thing. This leads coders to look at the web form as connected to the server-side code. This is not correct.
When the form sends data to the server-side program, it is just like starting to run that program again, from scratch. The data the form provides is like the command line parameters that you would give to your regular program at startup. There is no other connection between the form and the program. In fact, if you know the correct format for the form data, you can send that data to the program without using the form!
As with all user inputs, assume that you must validate the data and make sure it is the correct type and size. Sloppy data validation makes for a security hole in your web site and lets the bad guys walk right in. Only by assuming that your users are hostile or stupid can you ensure the safety of your server.
What about Database Code in the Program?
Most web projects anymore require a connection to a database management system (DBMS) to maintain the huge amount of data available. This makes the Internet extraordinarily more useful than it would otherwise be. Undergraduate Computer Science programs rarely teach database theory and practice with any great depth and this leaves coders uncomfortable with database interaction.
To make things worse, the primary language for databases is Structured Query Language (SQL). SQL is a different type of language from the ones most coders use. Web development usually uses Java, C#, PHP, or similar, and these are Imperative Languages. In these languages, you tell the computer what to do one step at a time (do this, now do this, etc.). SQL is a functional language, that is, it works more like a mathematical function. In this case, you don't tell the computer how to do the command, you tell it what the results should be equal to. If that sounds weird to you, you're not alone. This is the main reason coders have trouble with databases.
The trick is to remember good coding practice. Separate out the database stuff as much as possible. Also keep in mind, database calls work with your code no differently than calls to any other function. You call the function, passing in the relevant arguments, and you get a result back. The database call will probably return a set, but your programming language will probably treat it like an array.
So, In Conclusion
The first thing for the new web developer to do is stay calm. Panicking never solves the problem. You need to stay focused on handling this like you would any other programming project.
You need to follow good programming practice, particularly in reference to the Model-View-Controller concept. Designing the project, dividing it into smaller pieces when you can, and code reuse are imperative. Keep good design documents, updating them as you make changes.
Be realistic about your skills and the amount of time you have. Know that it will take some time to get the hang of something new and that you just have to keep plugging away at it. Also, focus on function first, and then worry about pretty. Teams of specialists with lots of experience usually build the really fantastic sites you've seen on the Internet. Your first few web sites probably won't compete in the same league, but that is ok. The experts didn't start out as experts.
When possible, see if you can get some experts of your own. Talk to a database developer or a graphic designer about their areas. Even if they can't take on that part of your project, they may be able to give good advice. You should also be aware of the plethora of online resources available to you.
The most important part, and I cannot stress this enough, is that you have to stay calm. Whatever you do, do not panic. It's just a programming project where you tell a computer what to do. If you have been programming at all, you know you are just telling a bunch of switches when to turn on and off. There is no magic and there is no mystical secret. Do not panic.