|
JavaScript @ Web Programming
Programming Shed : Programmer Store & Resources |
|
|
|
JavaScript Index - JavaScript Book : Building Professional Web Sites with the Right Tools
by Jeff Greenberg, J. R. Lakeland Paperback: 534 pages Dimensions (in inches): 0.87 x 9.21 x 7.00 Publisher: Prentice Hall PTR ISBN: 0130843172; 1st edition (August 10, 1999) Provides a tour through one of the many approaches to the entire process of creating a fully functional Web site, and instruction on obtaining and installing the tools, creating the graphics, designing and developing the database, Web pages and their elements, coding the applications and publishing to the Web. Softcover. DLC: Web-sites--Design. Card catalog description: "Make today's hottest Web technologies work together to create a site that achieves your goals, looks great, and works great, tool Everything you need to know is here, start to finish - from planning through development, testing, deployment, and beyond. Along the way, you'll discover how to get fast results with Visual Studio 6, FrontPage, Active Server Pages, VBScript, JavaScript, Paint Shop Pro, and many other great tools. Best of all, you won't just learn what to do, you'll learn why - as well as what not to do!"--BOOK JACKET. From the Inside Flap: Preface One byte. If you were to ask a dozen long-time programmers to name a single industry event that impacted their profession in the most far-reaching manner, you would receive at least ten unique answers (or more likely 10.25, considering the audience). I've pondered this question at length and have zeroed in on my answer. There's a story, hopefully an interesting one, behind it, so I'll keep you waiting for my answer just a while. I joined the computer industry in 1977, an amazing period of technological beginnings after what seemed a long, relatively stagnant period. I was fortunate to learn a large breadth of programming languages, some still in use, some now lost in antiquity: BASIC, FOCAL, COBOL, FORTRAN, ALGOL, APL, Assembler, PL/1, SPL and RPG; C and C++ came later. The fortune from this knowledge was an intimate understanding through comparison of what makes a compiler tick, and as a result an understanding of how better to create an application. I was also fortunate to make use of these programming languages, and dozens of variations of development tools and middleware, on several different computer systems. At the time, dominance in the marketplace was held by the mainframe. I programmed an IBM 370 mainframe. I used an IBM 029 alphanumeric card-punch machine to create the cards that made up both the source code and the Job Control Language the machine required to compile and execute programs. I suppose these cards now exist mainly in computer museums, so for those of you who never saw one, each card had 80 columns (see Figure P-1). Columns 1-6 were reserved for line numbers (we were too lazy to number our cards - a decision which would haunt you if you were ever to drop your deck of, on average, 200 cards and have to put them back in order). Column 7 was only used if the card were a continuation of the card that preceded it. Columns 8 through 72 were used for the actual COBOL instructions, a styling used today despite the fact that the days of punch cards are long gone. OS/JCL was something that, once mastered, stayed with you. I can still rattle it off: Figure P-1 A standard Hollerith card. Card courtesy of the Computer Museum of America//MYPROG EXEC //SYSOUT DD SYSOUT=A//SYS005 DD UNIT=TAPE, LRECL=80, BLKSIZE=240, DISP=(,KEEP)//SYSIN DD * Eventually we were able to do data entry with a teletype and with one of the first CRT's (Cathode Ray Tube) to hit the market. The teletype was always a mystery; you could tell where in the processing cycle the system was by the way the print ball would stop, pop up and down, and rotate. The CRT was a blessing. It still required the same 80-column format, but at least there was a backspace. Another system at the high end was an IBM 1103. This was considered to be a minicomputer at the time. It also used cards, and the card reader was so slow that you could see it sucking the cards through one by one. When designing applications for these beasts, you only had to remember that the input was limited to 80 columns, and the output to 132 columns. There were columnar pads in both sizes that we stocked to facilitate designing reports and input files around the column parameters. At the low end I entered the PC market before the first PC. I wrote my first applications on a Canon programmable calculator. It was precisely that, a large desktop calculator with thermal paper tape. It could handle 200 instructions or 2,000 bytes of data at a time. Connected to it was an 8" hard-sectored floppy drive, and an IBM Selectric typewriter that had a RS232 port. After executing 200 instructions, you would fetch more by issuing the commandI/O 76I/O 90I/O 90I/O 9200I/O 9100·m20RM20I/O 9I/O a So really, there were only 200 instructions less those 20 available. Entire applications were written by using functions still on calculators: Store Memory, Recall Memory and Accumulate Memory (M+). What a debugging nightmare! If the users needed to enter alpha characters, they had to press a completely nonintuitive series of keystrokes, then press the character keys (on a calculator keyboard that didn't resemble a typewriter keyboard in the slightest), and another series of keys when they had finished. About 1978 my Canon was replaced with an Ohio Scientific computer. Once we got the device drivers working, we had a working microcomputer with a boot choice of three internal chips: the Z80, the 8080A, and the 6502. With this micro came BASIC. This version of BASIC allowed computed GOTO and GOSUB statements, which led to debugging nightmares like:10 GOSUB VAL(LEFT$(Y$,3)) but it didn't have RENUM command, so I had to write one. This machine also made it possible to present the user with a menu because the screen supported the ASCII codes 10 through 13, which allowed the cursor to be moved in a nondestructive manner. The file I/O was challenging and fun because it was direct, so functions had to be written to place the file cursor at the right point prior to reading or writing. The microcomputer allowed the 132-column output format to be broken to some extent, because it did provide a means of sending output to the screen. However, despite its allowing the cursor to be moved, the cursor could not be absolutely placed. That is, if I wanted to put the cursor in the 25th column of the 15th screen row, I had to do this by starting at a given point and have the cursor move one position at a time relative to that point. This is still the way that many UI screens are drawn, but the positioning is not accomplished via a loop in a BASIC program. So full UIs were still just conceptual. At the middle of the market was Hewlett-Packard's HP3000. I wasn't working with the original model (the Series CX), but close: a Series II, the third in the line. A large difference here was that I could touch the system, start it, shut it down, and communicate interactively with it. There was actually some comfort in the immediacy and the machine's "willingness to converse" with me. The communications were via a terminal, the HP 2640, one of the finest terminals ever made. And this terminal brings me, finally, to my answer to the question I posed. The single industry event that impacted my profession in the most far-reaching manner. One byte. And that one byte is the escape character, ASCII 27. You see, the escape character was used to get the attention of the terminal. The receipt of that character told the terminal that there was going to be a string of characters following the escape character, an "escape sequence," and that every character received after the escape character up until an uppercase character would be a request for the terminal to provide a specific service. These services could include resetting, performing a self-test, performing tape functions (for the 2645 models that supported an internal tape drive), and, germane to this discussion, formatting. Oh the bliss. With a sequence of Esc &dA, I could make text blink. With Esc &dD, I could underline the text. And with the wonderful Esc &dJ, I could reverse the video (bright background, dark foreground) of characters. If I specified a column and row combination, then ended sequence with `Y,' I could move the cursor to any absolute address on the screen, and with a different terminating character move the cursor in a relative manner. This was my first opportunity to code a UI. I could highlight fields to draw the user's attention, even put a status line at the bottom of the screen. If the user typed something erroneous, instead of trying to stop them in mid-flow I could wait until they requested the screen to be accepted, pop an error into the status line, highlight the erroneous entry, and move the cursor to the offending field. Wow! Most of what I've coded since then has been an exercise in improving the UI. That's what receives the majority of my consideration when coding desktop applications and creating Web sites. There is one all-important facet to providing users with a visual interface: draw the users in and make them comfortable enough to stay awhile. This requires a well-designed interface to a well-designed application. They balance each other, and if either is insufficient, the users will either not use the application, or, if they have no choice, use it under protest. Certainly the presentation to the user is only one part of what's required for a Web site, but let's face it, there's no sense in having the rest of it if there's nothing for the user to see. And always remember, they might be coming to your site for the information, but if that information isn't presented in an appealing manner they won't be back! And for the programmer, what a joy to see that drop-down list drop down, that button respond to the mouse click, that text field change when the radio button is clicked. The feeling is even better when you see the page counter incrementing from the people visiting the Web site that you created. Figure P-2 HP 2640B Terminal Building Professional Web Sites with the Right Tools takes you through one of many approaches to the entire process of creating a fully functional Web site. I've tak From the Back Cover: Build complete, interactive Web sites from scratch, using Microsoft's hottest tools, plus JavaScript and PaintShop Pro -- and have fun doing it! Make today's hottest Web technologies work together to create a site that achieves your goals, looks great, and works great, too! Everything you need to know is here, start to finish -- from planning through development, testing, deployment, and beyond. Along the way, you'll discover how to get fast results with Visual Studio 6, FrontPage, Active Server Pages, VBScript, JavaScript, Paint Shop Pro, and many other great tools. Best of all, you won't just learn what to do, you'll learn why -- as well as what not to do! Start by identifying your site's goals and making the business case for building it. Next, create a high-level design; make key up-front technology decisions; and plan for feedback, advertising, and smooth site evolution. Then, discover easy, practical techniques for accomplishing all this: • Create great web graphics and navigation with Paint Shop Pro and Microsoft Image Composer • Integrate databases into your site -- step-by-step! • Use Cascading Style Sheets to enrich the look and capabilities of your pages • Provide interactive database-driven content • Build feedback pages and provide site help • Plan and run site tests -- and go live! Hands-on and practical, this book covers the nitty-gritty, day-to-day tasks other Web development books skip -- so you can build your site faster and more effectively than you ever imagined! About the Author: JEFF GREENBERG is a consultant for Hewlett-Packard with over 20 years of application and Web development experience. He co-authored A Methodology For Developing and Deploying Internet and Intranet Solutions (Prentice Hall PTR). Greenberg currently lives in Powder Springs, Georgia. J.R. LAKELAND is a writer, sailor, Harley rider, and co-author of A Methodology For Developing and Deploying Internet and Intranet Solutions (Prentice Hall PTR). Lakeland currently divides his time between England's Cotswolds and Atlanta, Georgia. Customer Reviews A Tool-Based Approach, November 22, 1999 Reviewer: Steven L. Alpert from Boynton Beach, Florida This book's fun, and I like the idea of choosing particular tools and showing how to use them together. I've been a C-UNIX-Informix programmer for about 10 years now, and I'm scrambling to gain skills in the web programming/design arena. This book's approach works well for guys like me who need to get familiar with a bunch of new tools and technologies, and quickly. I think you'll like this book. Good for seeing an implementation of ASP, but otherwise..., July 30, 2000 Reviewer: A reader from Alberta The best reason to read "Building Professional Web Sites with the Right Tools", I think, is to see a thorough example of how Active Server Pages can be used to make a web site "dynamic". But you'll need to know something of ASP before you begin. In addition to ASP, the book explains all of the other steps in building the example web site, but it overtreats the simpler material and glosses over the complex. For example, there are pages and pages of figures showing what are basically the same installation screens for each piece of software you'll be using; meanwhile, VBScript code, used in ASP, is often put forth as if its purpose and mechanism is obvious. "Visual Interdev" is one of the "tools" the book requires, yet its function is far from obvious. The program is ostensibly for creating ASP pages, but ASP code is never presented in the context of using the Interdev software. Finally, the preface, having almost nothing to do with the rest of the book, goes on about programming nostalgia, and is tangential enough to scare off an earnest beginner. There is "something for everyone" here, but that's not a good thing, because you're paying for everyone else's portion :-). Who, then, is the target reader? This is, as a whole, _definitely_ not for beginners with no programming knowledge, and advanced users will find much of the book extraneous (how to install your software, how to make graphic icons in a paint program). Intermediate readers like me get the most benefit, in terms of the number of subjects which are at our level. Rated "Three stars" since the book has a fairly grand mission to live up to, and though I find the problems quite glaring, it is not "poor" by any means. Don't waste your money on this one!, July 15, 2000 Reviewer: Robert D. Merritt from Conyers, GA USA Worst book on web development I've ever purchased! Don't waste your money on it.. I glanced through the book once and tossed it on the shelf and never picked it up agian. It jumps from subject to subject never throughly covering anything. If you need a book on web development, select books by Wrox Press or O'Reilly. nuf said. Well... AMAZON how do I give it ZERO STARS? |
|
|
© 2005-2006, Programming Shed
|