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!
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
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.
You can keep the filter in a cookie on the user side. Granted not a perfect solution but it's one way to go.
Related
Lets say you are developing an web app that requires that you are able to Add/Edit items. The item form contains several input control. Would you separate the add/edit pages or use the page for add/edit and control via querystring (i.e. ItemAddEdit.aspx?isEdit=1)
The advantage I see in separating is that it is easier for the (non-technical) user to type the page and to determine whether it is add or edit. Also, when there would be specific changes to each page (if ever), it would be easier to change.
For the single page, well, you reuse code which eliminates some duplicate code and avoid possible problems.
And no, I can't use routing.
This is generally something which could be a subjective thing, because there's as many ways of doing things as there are coders, and a lot of it can be depending on how your system is set up generally.
But, if I were to recommend, I'd say the way you should do it if working with asp.net web-forms is to make two web pages (add/ edit) and then you use a user-control on those to group up the shared logic between the two pages. After all - that's why we have user controls.
In this way you can have both of your situations, by keeping logic in one file/class, but still have two entry points.
This would also mirror more how MVC does it, which could be considered a plus.
That being said - if your administration functionality is behind login etc, there's nothing to hinder for actually doing it in one and separate with the query string approach, and then just load the data if editing or display "empty"/base data when creating.
You shouldn't have the user type the addresses anyway, but click through the links to follow your flow, so the query string should be a minimal issue.
But for the sake of keeping your functionality clean and divided, I'd personally recommend going for two page / usercontrol approach.
I am currently working on a website to manage rental properties. I would like users to be able to go to a page, enter information for a particular property (address, owner, etc.) and "submit" that information. The problem I am having is I cannot find a good way to manage the information, as well as give users the ability to delete that information at will. I would like this all done on the front end as I can't think of a good solution without significant SQL injection concerns. Ideally I would like all the information displayed with a small (x) next to each row.
I apologize that may sound very convoluted and vague.
User submits information about zero to many of his rental properties.
User goes to another page (or same page) and can view and manage his properties
User sells property; Deletes one or more of his properties
If anyone can point me in the right direction I would be thankful!
You can use custom post types for properties (you'd have a custom post type called Property) and meta data for storing any arbitrary info related to each property. That's a rough outline of how I would structure things for a project like this.
You'll need to do a fair bit of coding for the front-end forms, validation, storing/updating/listing data. The good news is that WordPress will provide lots of nice things for you out of the box, like authentication/authorization, user management, a great mechanism for listing posts (a.k.a. your properties) and categorizing them.
Our team is building a new web site with ASP.NET. We plan to use a 3-tier architecture. The problem is that the controls shown on the web page need to be changed all the time according to the customer's requirements, which means adding a pair of label/textbox, or removing a pair of label/dropdownlist when the customer needs it. So the layout needs to be flexible and allow to easily add or remove controls, although it just shows some simple product messages like price, discount, tax, etc.
The previous version of the web site saved all the control information in a database, like control name, control type (textbox, label, dropdownlist), which page and panel it belongs to, etc. You can see there is a big performance hit because every time there is a request to this page, it needs to get all the required controls from the database and add them to the page manually, no matter whether the request is a postback or not.
We thought about adding the controls directly to the .aspx page, but in this case it will be difficult to change them later. We also considered holding all the controls' information in XML files, which may give a little performance advantage, but it still needs to render the controls all the time.
So this is the problem we have, to improve the app's performance and also meet the users' needs at the same time. Could anyone help me with any solutions or ideas?
PS: you can also ask questions if I didn't make it clear enough. Best regards.
This sounds like a good situation for User Controls. If all you're doing is toggling child-control visibility, then creating a user control with toggleable visibility properties should meet your needs. You can still use your backend to toggle visibility, but you'll only need to pull yes/no flags from the db instead of entire page schemas.
From an architectural standpoint, User Controls are great because they encourage modularity, code reuse, and lend themselves well to version control (UsercontrolV1.cs, UserControlsV2.cs, etc). The point on version control is especially great in cases where change requests require logic updates, or simply need to revert to a build that existed x iterations ago.
Now that is what i call a Flexible web-Application.
the controls shown on the web page need to be changed all the time
Who will change the controls? The client? Can you not just update the .aspx file and publish it to the server every time a control is requested to be changed?
but any way, its an interesting question. There is nothing else really that can be done except using a XML file.
I am curious as to what people would thing is the best way to implement this.
On my overview page, I have a data grid which is sortable and has custom filtering written for it. When you click on an item in the grid, it loads a separate page with details.
I would like to implement result paging through on the detail page keeping in the same order as the previous page data grid.
Now I've thought of a few ways to do this:
Change the link to be a postback and handle the sort order programatically
Sort filter and sort settings on application of the settings in the session
Pass the filter and sort settings on the query string to the detail page
None of these seem very clean to me, and option 3 is the only cogent option I've thought of.
Am I missing something? Is there a more elegant way to do this?
It is preferable to have url access to any details view that may be needed independently of the master.
Of course, you can have both postback and GET access, but begin with the url and querystring. I have had to fix numerous postback-only views to support direct urls, when the need has eventually arised.
If the filters and sort order are very complex and would require an elaborate querystring parameter scheme, I would think hard what is really needed for url access. Complex settings are best passed in a serializable .NET object in the Session or ViewState. You'll get .NET type safety and avoid error-prone querystring/form/cookie parsing. Session would be better if you need to pass these settings from another page of the application.
We have about 10 applications that basically do the same thing, all written using the Wizard Control for .Net 2.0. The flow they follow is pretty simple:
1. User selects option from a drop downs.
2. Next page has more options more narrowed.
3. User sees confirmation page.
4. Report is generated.
Some of these applications have optional pages, such as allowing the user to upload custom images for the report and allowing the user to select specific lines of data.
I'm attempting to merge these applications, but I'm not sure I'm approaching this the correct way. My first inclination is to create configuration tables in SQL to drive the menus that appear. So, for example, there might be a table with the WizardId, Name, Theme, etc., also a table of steps, and another table to link everything together.
Is there an easier way to approach this that I'm just missing?
We've been thinking through this issue lately and I've come up with two options that both seem valid, just have different uses. One way to do it, similar to what you have described, is to create the following:
A table that holds the wizard information
A table that lists the types of questions to be asked in each wizard
A table to hold the data entered by the user for each question
This is very flexible, but the problem is you have to dynamically generate all the controls you need to collect the information (textbox, drop down, radio, file upload, etc) and store how to display that control in your database.
The other approach that we have tried out on a recent project is to associate a user control with either each wizard or type of wizard step. It isn't as modular, but you have a lot of control over how the controls are arranged and how you collect the data.
I think both approaches are useful in different scenarios. Going with a database driven approach allows you to generate new questions and wizards easily, but lacks the user friendly approach that we wanted for our new application.