If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

There has got to be a better way

On this page http://www.ihatemyfurnace.com/goodman.html
I'm using switch and case to match up parts with a model number. This thing is getting looong and I'm not even halfway done yet.
Can I keep doing it this way without affecting the loading time? Or is there a completely better way to do it all? Maybe a way that would save me from typing so much? Right now I'm doing copy/paste and just changing part numbers and prices. I'm thinking that a database might be the answer, but I have no experience with those at all.

Thanks to anyone with some good advice, I appreciate ANY comments good or bad. I learn better that way.

Well if you have no server side processing capability available to you (PHP, JSP, .NET, etc...) then I guess it's any port in a storm. Yes this will be somewhat kludgy to implement if the only tools you have available to work with are HTML and Javascript. The one thing I notice that can be a showstopper for you is that your javascript application is depending upon cookies for critical application functionality. Cookies can, and frequently are, disabled by many users for various different reasons. Disabling of cookies by the user should not utterly break your web site/application but with the implementation you are currently using, that is just what will happen. For that reason I'd urge you to rethink your solution to one that does not depend upon cookies.

Assuming you have no server side scripting capabilities available (PHP, JSP, .NET, etc...) and you want to do this purely in DHTML/Javascript, you might try an AJAX approach something along the lines of this. . .and this is just me sort of brainstorming. Come up with a simple XML format where you put the specs of each furnace in a little XML file and save the XML file with the name of the manual, so for each possible value of your "manual" variable you'd have an xml file. . .so like gmp0503.xml, gmp0753.xml, etc...

Each XML file encapsulates the hilimit, venter, fsensor, etc...attributes for each possible expected value of the "manual" variable.

Now, when somebody inputs a value into the model text input box, use an XMLHttpRequest object to request the appropriate xml file for that model from the server. Use javascript to parse that xml content the server returns and dynamically render the content into the same existing window without having to refresh to another "yourproducts.html" page.

Now as for how to avoid having to type in all those part numbers and prices and such. . .I don't know how to help you there unless you already have that stuff existing in digital format. If you do have it in an existing digital format it should be pretty simple for a programmer of novice to intermediate skill level to write some kind of a utility to parse it automatically and produce the output in the desired format.

EDIT: Another possibility, if you are comfortable with XSLT, would be to link directly to each XML file and let the web browser parse it and display it using a given XSLT stylesheet. If you have no idea what XSLT is and have no desire whatsoever to have to learn yet another "language" then you could just stick to something along the lines of what I already proposed using AJAX.

I'm hosting with Godaddy.com so server-side scripting is available. I've been putting off learning PHP mainly because I'm still struggling with learning javascript.
HTML 5 is supposed to have a cookie-like way of remembering data from page to page but I can't find much information about implementing it.
I like your idea about making each model number a different file, but I don't know XML either. Couldn't it be done the same way (kinda) with HTML?
Thanks for your quick reply!

If you know HTML, you already know XML well enough to do what you need to do here HTML is just an XML vocabulary. With XML, it's just like HTML for the most part except you get to make up your own tag names.

If you don't want to use XML in the fragment files then you can use something simple like comma delimited (or whatever delimiter you choose) plain text, just as long as you can parse/tokenize it with javascript on the client browser side. There's no rule that it has to be XML, it's just that XML has some advantages in that the browser can parse it natively and build a DOM tree out of it which you can then programatically navigate easily. But there's no rule that an AJAX (XMLHttpRequest) request absolutely MUST return XML data that I know of. Here's a little sample fragment of the XML might look like.

It looks like you have a large set of data. How you store or import this data is up to you (there are a wide variety of methods available to you), but my recommendation is that you put it in a format that allows JavaScript to simply access the specific item it needs. Having such a long series of cases in your switch statement will eventually slow the processing of the JavaScript. The actual page load time (as in how long it takes for a person to load your web page) will remain the same, as it's the same amount of data.

Try storing your data in a JavaScript object or an array. Since you have multiple values for each, you will need two dimensions. I recommend objects because they are easier to deal with, although you could also use multidimensional associative arrays for this purpose as well.

This would allow you to access each of your items as a sub-object of your "manual_data" object, and each sub-object has all of the properties (identified by name) stored and ready for use. This would let you access whatever you need with one line:

Code:

// if "manual" is "gmp0503," then the below will alert "1370912s"
alert (manual_data[manual].hilimit);

I initially had thought about proposing something similar to what Jona proposed above but I decided against it for the reason that it does not alleviate the problem of having to load ALL the data for ALL the furnaces and their parts whenever somebody hits the page regardless of whether or not they are even going to look at any of it. Chances are they are going to request the data for maybe one or two of the possible furnaces at most so by loading all that other data every time you're just wasting bandwidth and slowing down the performance needlessly. I feel the best approach would be a hybrid of his suggestion and my own. Use my approach to limit loading only the furnace data you need on demand. Use his approach to store the data in the javascript engine memory for a given furnace once the data for that given furnace has been parsed from its corresponding data xml (or text) file.

I initially had thought about proposing something similar to what Jona proposed above but I decided against it for the reason that it does not alleviate the problem of having to load ALL the data for ALL the furnaces and their parts whenever somebody hits the page regardless of whether or not they are even going to look at any of it. Chances are they are going to request the data for maybe one or two of the possible furnaces at most so by loading all that other data every time you're just wasting bandwidth and slowing down the performance needlessly. I feel the best approach would be a hybrid of his suggestion and my own. Use my approach to limit loading only the furnace data you need on demand. Use his approach to store the data in the javascript engine memory for a given furnace once the data for that given furnace has been parsed from its corresponding data xml (or text) file.

Ahurtt,

You are correct, and I agree. His question was posted in the JavaScript forum, and so I answered his JavaScript question. There is no argument to be made that the data should be stored externally and imported, and I would agree that JavaScript (specifically, Ajax) is the most appropriate and efficient way to do this. Although JSON would be more useful, I think, than would XML, since JavaScript would be able to import JSON as a JavaScript object natively, whereas the XML data would have to be processed, but I digress. The fact of the matter is that the problem is in two parts: one is the JavaScript, and one is the data storage format. We provided a solution to each of these problems independently. I fear that we may have confused the OP, however.

Actually what both of you posted, I understand, in a somewhat limited way. LOL
You've given me some direction. I'll take a couple evenings and see what I can come up with.
I agree that the data shouldn't all be loaded with the HTML and now you've shown me where to direct my energies. I think it will also reduce the amount of typing I have to do.
Thanks!

As the page holds about 75 records, and each record is just a little text, I wouldn't be too concerned with storage-methods. If the webserver is serving these pages raw, not compressed with g-zip, we are talking about a total size of 49 K, and since everything is done on-page with javascript, the page loads only once per "use".

If this page does what you need it to do, then let it be. As you have no experience with Ajax, PHP or database development, and this page is all you need it for, and you don't wish to spend some time learning that part, don't worry. Your page works.

As the page holds about 75 records, and each record is just a little text, I wouldn't be too concerned with storage-methods. If the webserver is serving these pages raw, not compressed with g-zip, we are talking about a total size of 49 K, and since everything is done on-page with javascript, the page loads only once per "use".

If this page does what you need it to do, then let it be. As you have no experience with Ajax, PHP or database development, and this page is all you need it for, and you don't wish to spend some time learning that part, don't worry. Your page works.

- Spinner

His complaint in the original post was that the cases in the switch were getting long and unwieldy and he wasn't even halfway done yet. So from that information we can easily deduce that eventually there will be 150+ cases in his switch and that is just plain ugly. His desire (and a commendable one in my opinion) was to find a more elegant solution. That is what we have attempted to provide here. Also, with his current implementation, as I outlined in my original reply earlier, his page does not "work" if a person disables cookies. Go ahead and try it yourself. Sadly the world is already full enough of half-baked developers calling themselves professionals without need of you going around discouraging the novice who wants to do a better job from trying to improve their skills and do things more elegantly. Saying that something that depends wholly on an option the user can simply turn off for its primary functionality "works" seems to me like saying that a furnace that blows air but produces no heat "works" because you've plugged in a bunch of electric space heaters and set them in front of all the air vents. That's not "working" in my book.

There will be about 175-200 records to finish off the Goodman furnaces. Then I'll move to Carrier, Rheem-Ruud, Lennox, etc. So eventually there could be well over 2000 records. I'll also have to consider how easy it will be to change prices.
I'm opening a can of worms here, but I like the results I'm getting so far. Changing it so it operates better will be the icing on the cake for me.
Thanks for all of the comments, you guys are great!
Question: Is learning database creation/operation really all that difficult?

I would definitely recommend a database to store the data. Additionally, you could build a program to interface with the database so that you can manage the data visually, so no code will be required to update information in it. This is exceptionally helpful because it allows you to delegate the task of updating and maintaining the data to others with minimal effort.

As far as how "difficult" it is to learn a database system, I would say it's actually pretty easy. Most database systems operate through a query-type command system, where you send different queries to the database as text commands, and the database performs whatever action(s) you request. Creating the database can be done visually, as there are tools for I think every available database system that allow you to visually implement your database schema.

Question: Is learning database creation/operation really all that difficult?

"Difficult" is a subjective term. Anybody can probably follow a few examples, read a couple beginner tutorials, and produce the equivalent of a "hello world" application. To create a simple database for what you are trying to do here should not be particularly difficult at all but I say that as a developer who has been working full time in a professional capacity in the industry since 1997. But there are a number of libraries for PHP (since that is the server side scripting language you have available to you) to facilitate integration of various open source database products into web applications. To do such an integration would naturally require an understanding of how to program with PHP as well as an understanding of SQL. It would be more complicated and perhaps overkill for what your immediate need is but using a database allows for greater flexibility and expansion in the future. . .because you can develop custom queries against your data which would not as easy using a file based XML or JSON approach. Say for example you want to add the ability for users (or for yourself as an administrator / business operator) to query all the furnaces which use a given part number. It's much quicker easier to do this with a database than by writing a server side script to parse through a bunch of XML or JSON files. Do you know what database servers you have available to you with go-daddy as your hosting provider? Do they have a standard or do they allow for you to install and administer your own? These are things to consider.