Mike Wood

About Mike Wood

Michael Wood has been with Beacon 9 years. He provides transactional programming expertise mostly in VB.NET and SQL Server. In the past he worked in the corporate worlds of AT&T and IBM.
20 07, 2015

Different ways to display results using the Nextopia Search API

By | 2017-06-16T12:38:16+00:00 July 20th, 2015|Categories: Web Development|

blog1Here at Beacon we use Nextopia to provide search results on several of the sites that we support. They do a great job of supplying an easy to use search solution for your site. There are several different ways to get the Nextopia search results content on your pages. You can make the search calls via java script snippets on your page. When called this way, Nextopia will replace content on your page with their search results. You can also use their API to initiate a search. The API returns an XML document which you can parse and display the results however you please. In addition to traditional search page listings, we have used the API to show Nextopia search results in couple of other interesting ways. I’ll go over these below.

You can use Nextopia to display a product filtering area. This in itself isn’t surprising. The API call to Nextopia returns both product results and filtering (or refinement) information that allows users to drill down to more specific products. However, you don’t have to limit the filtering area to a search results page. You can include it on any page that you want. For example, we have set up this “filtering nav” on several ASPDotNetStorefront sites. Storefront doesn’t have an out of the box filtering solution that you can use to narrow the results on the “category” or “brand” pages. However, if your site is already using Nextopia, you can call the API from the listing page (or xml package for an ASPDotNetStorefront site), passing in the category (or brand) name. You’ll get a nice “filtering nav” in the refine results area of the data returned by Nextopia. Stripping just that “filtering nav” from the search results allows the page to use the storefront code to display the products or sub categories associated with the top level category (this helps in search engine visibility) and gives users a way to quickly navigate to the products they might be interested in.

14 03, 2011

Look or “View” Before You Leap

By | 2016-11-18T14:24:52+00:00 March 14th, 2011|Categories: Cascade CMS|Tags: , |

I think a good habit you can get into as a developer is to think about several ways to tackle a task instead of implementing the first solution that pops into your head.

For example, a client recently decided they wanted to duplicate one of their sites.  So we copied the code and the database. (The site’s data is stored in a Sql Server database.)  Part of the database contains data used for reporting purposes. The new users have access to this data but will not be updating the data. At first glance, if we used the copied database as is, we would need to duplicate the process that populates the reporting tables. However, we don’t want to go that route.  In addition to storing two copies of the same data, changes to the process would require coding the same updates in two different places.

The next idea was to change the all the database calls that reference the reporting tables to access the data from the original database.  This would work but would require changing a lot of calls in several stored procedures that are used to pull the reporting data from the database.

How do we access the data without changing any of the select statements wherever they may be? We then set up a view in the same name as each of the tables from which we wanted to access data from the original database.

Say we have a table named “products” in the original database.  We didn’t include that table in our new database. Within the code on the new site, the select statement might say something like SELECT name, color, weight FROM product.  If we changed the select to pull from the original database, the select statement would look like SELECT name, color, weight from originaldatabasename…product.  Instead of doing this, define a view named Product. This view contains the select from the original table. Now any Select statement that needs data from the original table has access to the data in the table via the view.

This saves time now and in the future in that we don’t have to change all the Select statements to access the Original database’s tables.

19 12, 2010

Prevent Errors From Being Written to Application Event Log

By | 2017-02-21T11:48:59+00:00 December 19th, 2010|Categories: Web Development|Tags: |

I was going to write about the Peloponnesian War, its ramification on the course of Western Civilization and how that ancient struggle correlates to the Microsoft vs. Apple battles we see today. But, in addition to the fact that I really don’t know very much about the Athenians or Spartans, that war was fought, as my son Tyler would say, “a very long long day ago”.  Instead I’ll write about how in ASP.NET you can prevent an error from being written to the server’s application log.

Let’s look at the “A potentially dangerous Request.Form value was detected from the client“ error that can show up on an ASP.NET page.  This error is thrown when potential HTML or other script tags are entered into a textbox of an ASP.NET form. This error gives you something looking like …..

The error itself isn’t a bad thing since it helps prevent script injection attacks.  (If you want to allow script tags to be entered on your form there are several things you can do. Check them out here.) Our problem was that when an unaccounted for error is thrown in ASP.NET, the error is written to the server’s application log. We have a utility that reads the application log and email’s the system administrator any errors that show up. Our administrator had to screen all of these emails in looking for one’s that we really needed to see.

The solution is to put some code into the Application_Error method of the global.asax file that will trap and remove the error that we don’t want to log.

Notice that after clearing the error we need to redirect to another page. If, after clearing the error, we allowed the page to load, we would see a blank page. (The error that would have been displayed is erased by the Server.ClearError() command).

You could also include the code in the page’s “Error” event.  However, you would have to include the code on every page instead of in just one place.

So, if you have any interest in preventing an ASP.NET error from being written to the server’s Application log, consider using the Application _Error method of the site’s global.asax