Finding a value in a hashtable based on wildcards?
I'm not sure the subject explains well enough what I'm trying to do.
I'm building a smart redirect system to catch 404 errors on a web site then redirect them to a resource based on values a user enters to help decide where to forward the 404 resource.
For example, MyProduct.htm comes in, but I have a new web site and I want this to forward to Products.aspx
Another example: Detail.aspx?ID=3 comes in (pointing to a product in an old store) and I want it to redirect to ProductInfo.aspx?productid=38
So, I can capture all the 404 pages that are coming in, but I have to take this page value Y and figure out which row that the user entered matches this.
What makes this tricky is I'd like to allow users to enter wildcards. Such as *.htm points to Default.aspx. Or *Neal*.php points to Neal.aspx or Detail.aspx?ID=2-25 to point to SomeURL (notice it could be a parameter value from 2 to 25).
So, the configuration table a user configures the redirects would look like:
*.htm -----> Default.aspx
*Neal*.php ---> Neal.aspx
Detail.aspx?ID=2-25 ---> http.....
So the problem is, I catch a 404 and determine it's SomePage.php. How would I go through the table and determine WHICH row matches this item so I can determine the target? Or in another case, Detail.aspx?ID=12 comes in, how would I determine this fits a row in the configuration table to find the result?
So in other words, it's reverse of what we normally do with a database. Typically we would use SQL to do a LIKE search using Wildcards. Instead, I have the value, and I have to determine which Wildcard value would find this result, i.e. reverse engineering the search.
Again, using a simple two column dataset. If necessary, I could dump it to a Hashtable...
Do you see yourself as the developer building the table or an end user? If you are building the table then one of the database fields could contiain regular expression format strings. It wouldn't be fast but you could loop through each of the items in the config table doing a compare to the 404 source to the regex fuctions until you get a match. This is amost what you have defined in your example.
Just one idea.
I created the table with two columns. The end-user enters the Old Resource and New Target Resource: So they get a grid, two columns, they enter:
There is also a second section where they can view the collected 404's (left column populated) and they enter the target resource URL
Any suggestions on doing this? I am not proficient with RegEx. Any resources you can steer me to?
Thanks for the response.
The String Like comparison using wildcards will work for most of the examples you gave except for the range example
and you will hate me for this one, but is the RegEx reference from MSDN
If you want to pursue the RegEx solution for ranges, let me know. I think that the range solution may be best handled by a subroutine that would accept the users input and convert it to a regex string that would be saved to the database. I think this generated string could also be passed to the like command mentioned above.
I'll take a look at the String compare LIKE option! I get locked into "DB thinking" as that's most of what I do. Looks like this would work. However, I guess I need to loop through each of the Source values and see if that would match the Target value, instead of taking it in reverse and seeing what Source meets a requirement of the target?
On another note, the DataSet is in memory. Do you think HashTable in memory is faster? They are both in memory...but something tells me to dump the DataSet to a HashTable then iterate the hashtable. Any thoughts on fast iterations to do this?
Based on my limited experience with the RegEx operations the amount if time saved DataSet vs Hashtable will (probably) not greatly effect the performance of the lookup function overall.
As an afterthought: for ranges you might try seperating the source string from the parameter value. Using your range example:
Detail.aspx?ID=* , 2-25 ---> http.....
Then using the like command you could get a match on detail.aspx?ID=* then separate the range field based on the dash separator to determine the lower/upper range of values. This would create a two stage match but would be easier than working with RegEx strings example:
Detail.aspx?ID=* , 2-25 ---> http..... 1.aspx
Detail.aspx?ID=* , 40-47 ---> http.....2.aspx
Detail.aspx?ID=* , 30-33 ---> http.....3.aspx
Okay, thanks! The range option may come later, it's less important. I'll think on this...one of those where you have to wait for the lightbulb to come on!
Thanks for the help!
My problem is I usually blow a fuse before I get the light on.
Originally Posted by neal007