views:

45

answers:

3

Hi,

So I have a .Net website I made and part of it is a page where a database table can be filtered, queried, and displayed. Then I allow users to select an individual row to either edit or delete. Both of these functions are performed on their own separate pages. Recently I was asked to add functionality to the first page to allow for the query filtering to be preserved between visits. For example, if a user edits a row then returns to the table, the filters they selected should still be in place.

My question is what's the easiest way to do this. The problem is that many of the filters are dynamically generated based on another table in the DB so they aren't statically coded into the page. One option would be passing the filter string in the query string but this seems unpractical because of the possible great length it may be. I also thought about opening a new window but there are concerns about security and data duplication. I could also use an iframe to load the pages and hide the original content until done editing but I'm not sure how to access clicks from within the iframe in the surrounding page, or if this is even a good idea.

Any help/suggestions would be greatly appreciated.

Thanks!

+3  A: 

You could encapsulate your functionality into a User Control that both pages can use.

How to: Convert Web Forms Pages into ASP.NET User Controls

rick schott
+1. This question doesn't sound like a case for another page, but just an encapsulation of controls+logic from another page.
p.campbell
When you say create a user control what functionality are you referring to? The query filtering is only being done on the original page.
rpf3
I am saying have one page that does your query filtering and include the other page logic as a user control.
rick schott
Did my answer help you solve your problem?
rick schott
A: 

You could use a SESSION variable to store a Dictionary<string, object> or something similar which contains keys identifying each table and values representing the filter. The actual filtering options shouldn't be too much information to store for a given session.

Without knowing how your application captures the concept of a filter it's a little difficult to offer a fully-qualified solution, but session seems like a decent option.

Nathan Taylor
Well on the page a filter is a dropdown list but it is basically a way to write out the SQL that will appear in the WHERE clause. Each filter's id is the id of the SQL column and the values of the ListItems are the possible column values. They are all strings or ints.If I do what you are saying and store a a Dictionary<String, String> object in the Session for each Table page will this be costly? I don't really see a given user visiting more than one or two unique Table pages unless they are an admin since each user will only be concerned with their own group
rpf3
This seems viable to me then. The memory cost of storing this kind of data in session shouldn't be high at all. It really depends on how you want to go about serialize the filter values. Perhaps if you defined a "TableFilter" class that encapsulated different filtering options you could then serialize a Dictionary<string,TableFilter>.
Nathan Taylor
A: 

You can keep the filter in a cookie on the user side. Granted not a perfect solution but it's one way to go.

Ian Jacobs