"Paul Bruneau" <bruneaup@NO_SP AM_rogers.com> wrote in message
news:66******** *************** *********@4ax.c om...
Hi,
I hope someone can help me make a working shopping cart, as a learning
tool.
If I have a "Product Demo" html page with a "Buy Me" button, there must be
a simple javascript method of storing the necessary product information.
There could be several fields involved... [ price; quantity; product ID
number; manufacturer; the list could go on and on]
Then there ought to be another javascript method that can create a new
document based on the list a user has built selecting product from several
of thos "Buy Me" buttons.
That appears to me where my brain always farts! I can't seem to get my
mind wrapped around how Javascript carries any variables around from one page
to another.
Once I do this and understand it, I'll be happy to jump into the several
full shopping cart examples..... but catalogs and databases are beyond me at
this point.
I just want to follow the K.I.S.S. principal to understand the very
basics.
Anyone care to help me here?
Hi Paul,
In reality, no useful shopping cart can be handled entirely by client-side
JavaScript. The concept you're trying to understand doesn't make any sense
because you're missing the most important part of the equation. What you
need to start learning is server-side scripting/execution. If I were you,
I'd start Googling around the Internet looking for information about PHP
(php.net is a good place to start). It is probably one of the easiest
server-side execution environments to learn and its scripting language
(Zend) is very similar to JavaScript. PHP has been attracting a huge
following over the last two years and is now deployed on most web hosting
providers' web servers. PHP runs very well on Windows-based/IIS web
servers, but it is intended to run as a built-in Apache module on the Apache
web server for Unix operating systems. PHP's strengths over other scripting
environments is that it's very fast (as an Apache module) and was built upon
an SGML document model that makes it very friendly with all types of data
transport models (it can be "woven" into an HTML page without requiring
archaic server-side includes or fully script-generated documents).
Now that you've heard my sales pitch, you'll also want to learn as much as
you can about HTTP. It's such a simple, no-frills protocol that it's
amazing how few people really take the time to understand what's going on
"under the hood."
HTTP allows for several data request and supply methods that make passing
information between pages trivial. In a nutshell, there are two important
request methods: GET and POST. The GET method is the most common (since all
requests that aren't explicitly set to POST are queried as a GET request).
A GET request can be as simple as asking for an HTML document:
GET /index.html HTTP/1.1
and can be as complex as a key/value list of data:
GET /processor.php?i d=123&fullname= Bob+Johnson&pho ne=5551212&favc olor=blue
HTTP/1.1
In an anchor tag in an HTML document, you can issue GET queries statically:
<a href="dosomethi ng.php?operatio n=play+a+game"> Play a Game!</a>
The other method is POST. This is most typically used when you want to send
a lot of data to the server through an HTML form:
<form method="post" name="post_test " action="process or.php">
<input type="text" name="id" value="123" />
<input type="text" name="fullname" value="Bob Johnson" />
<input type="text" name="phone" value="5551212" />
<input type="text" name="favcolor" value="blue" />
<input type="submit" name="submit_bu tton" value="Submit" />
</form>
Any of these request methods will send a list of data to the server. In the
GET method, this is sent as plain text in the URL (simple). In the POST
method, this is sent as plain text in the request header (more complicated,
but nothing we have to worry about since the browser constructs the POST
request).
These examples just touch the surface. To understand how to use them,
you'll need to learn a server-side execution environment.
If you want a list of some of the popular server-side execution
environments, here you go:
PHP, Perl, JSP, ASP[.NET]*, C#*
*Indicates a proprietary language specific to M$-based web servers. PHP,
JSP, and especially Perl are very powerful, open-source (free) solutions
that are available to any web server that wants to support them (even M$
"servers"). ASP (in all of its incarnations) and C# take a lot of voodoo to
work on anything but a Windows "server."
If you want a history lesson, learn Perl: it's slow unless the server has
been really tweaked and tuned to run Perl efficiently. Even then, some
things are just easier with Perl, so it's a nice tool to have in the box.
If you want to spend time compiling programs like you would in C, JSP is
nice. JSP (using the Java programming language) can be difficult to use
unless you're used to ADTs and OOP in C++. ASP was created with the idea
that you can use any programming language to construct server-side
applications. Out of the box, IIS servers allow you to code ASP using
JScript (a close, but not identical, cousin to JavaScript) and VBScript
(M$'s idea of a scripting language based on Visual Basic). I've never used
C#, so I don't know the advantages of it over other scripting/programming
paradigms. I just know that Visual Studio isn't free or cheap. (IMHO,
_that_ is why all of the M$ proprietary solutions will never be able to
compete with stronger, faster, and more reliable alternatives that cost
absolutely nothing.) Out of the box, PHP supports one scripting language
(Zend: a JavaScript-like language). PHP is starting to mature as a product
and will probably become the dominant server-side execution environment for
all of the Apache-based web servers (more than 50% of all the web servers on
the Internet). So far, PHP has never let me down in features and
capabilities. You can do everything from printing the current date in the
corner of an HTML document to progrmatically generating Flash, images, and
PDFs on the fly. Coupled with MySQL (one of the leading open-source
database management systems), you can create advanced web applications (like
shopping carts) with ease.
Hopefully, this has given you some direction in learning how to develop
web-based applications. I should tell you that jumping right into a
shopping cart will be a rather intense experience. Given the amount of
browser and server interaction that is required in building a robust
shopping cart, this is arguably one of the most difficult web applications
you can develop. Start small (like a news system or content management
system) and work your way up to things like shopping carts and online
community systems.
Good luck and take care,
Zac
