I have a 200+ case statement in Classic ASP which is getting out of control. It sets 5 variables, based on which case is selected. Address, Phone, Name etc. Just sets the variables and nothing else in each case.
Databases or files are not an option for this application.
Coming from the Perl world I would use a hash to store this info.
Getting out of control? I think it's already out of control!
Can you not categorise the cases into 'x' general areas and split down into helper routines?
Can you post an example of some of the cases? It's a little difficult to formulate something that would help you without it.
Brian, the classic ASP equivalent of a Perl hash is the Scripting.Dictionary object.
Depends on what you want for performance.
The case statement is ugly but does not consume memory that would need to be allocated.
However, you could create a class for your fields and load instances of them into a Dictionary. Perform this operation in the global.asp script so it only happens once. Store the dictionary in the global asp collection such that it is only allocated once but used with each page call.
My appologies for not getting too specific here... it's been a while.
This should be done with a database, but since you said that is not an option, nothing you will write will be any less complex than a switch statement, since it's all required to live in your code (according to your terms of no db and no files).
I mean, you could use an Excel Spreadsheet if the idea of a database is too complicated but technically that would be a file as well.
A lot of people use VBScript for Classic ASP, but you can use JavaScript / JScript on the server as an alternative. As a matter of fact, this is my preferred way of doing Classic ASP before finally moving to .NET (except in some cases, you will have to mix in VBScript for special cases, i.e. Disconnected Recordset, ExecuteNoRecords, etc.). It will provide you with better OOP support vs VBScript. Maybe you can try refactor that to.some sort of Strategy pattern afterward. Worth looking into I guess for better maintenance in the long run.
The fact that you can't migrate this over to a database or a text file is a bit of an issue as they would be the best solution for this type of data. However, if you have to have it in the code you could always try putting it into a matrix that you predefine. Then you could provide a function that returns the data from a given row in the matrix.