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.
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 building my own GridView in an ASP.NET project
I am drawing out my plans and I was wondering what the best solution is to a simple problem, paging and sorting.
The fast and easy way is using submit buttons (or similar) and POSTING the form back. That's also how the ASP.NET gridview works.
pro:
less overhead
con:
backbuttons
The second method is using links and the URL with GET requests.
pro:
backbuttons work just fine
direct link to certain position
con:
less reusable because of the dependence on url
The third method is AJAX
pro:
little overhead
con:
harder to implement
What design/solution would you pick and why?
Am i overlooking some pros and cons?
I add some extra comments to think about.
-The second method is using links and the URL with GET requests.
This is the one that you need to use, if your need web spiders (google) knows all the pages of your site, and be SEO friendly. This method have the problem that you can not have viewstate and each time you must render the page that you see on the url parameters with out knowing anything else.
With this case you probably have more problems if you wish to make edit on one line
-The fast and easy way is using submit buttons (or similar) and POSTING the form back
This is the method if you won to have many functionality on code behind because with the post back you have all the previous action that you have done, and the viewstate is working and can be used for that. Is not SEO friendly and if you like to make it you need extra code to write on the url just the page that you are now and need to land.
-The third method is AJAX
This is the method that must co-exist with the previous and not alone for the case that the browser fails to run javascript for any reason. If you do not care about that, the rest is that this method is also not SEO friendly and you need to make it, is cool, modern, and is a must for modern site, but if you going to make difficult things then you may end up with many issues that must be solved.
To summarize:
More than show data ? Post Request : Get Request ; // ToDo: make it ajax
I have a Plone Site where anonymous users create a "Subscription" object for a conference.
Fact is: a malicious user can call this screen a lot of times and crash my site. I can use a captcha to avoid it, but I would like to use it only after "x" attempts of the same user, something like the SO approach when a user tries to post a lot. Is there a module that does this for me? Show a recaptcha after a user tries the same url too many times?
For a start content in not the solution to everything. In your case having a custom content type for handling subscriptions seems like an overkill. Always ask yourself if what you are doing is really content-ish. Does it need to be contained, navigable, searchable whatever else content can be? For a conference subscription definitely not.
In brief you could:
Create a form and save its data in lighter objects than full content or use sql.
Use Products.PloneFormGen, which also has captcha support.
Concerning the captcha if you go the manual way and create everything yourself, you could use cookies to "remember" visits. See How do you get and set cookies in Zope and Plone?
It's obvious that your system is subject for manipulations in form of mass-registrations in every way without further measures like a captcha or additional email validation after submission of the registration form. But this is independent of flow control, DDOS etc.
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.
I'm trying to cache user controls and on some pages i want to cache single objects. There are multiple ways of implementing caching, and my head is breaking over it.
The way I see the caching options now:
You have the PartialCaching option which is set to cache the control for 30 minutes, and after that it clears itself... You have the varyByParam to identity the page by its querystring paramaters... or other vary options
But i just cant find an appropriate way to add caching to a control, and be able to clear the caching programmatically when i update one of the objects used in the control from the backend.
You can do HttpContext.Current.Cache.Insert(), which accepts a key on which you can destroy the caching item later by using remove... This can save objects in cache but can you use options like varyByParam?
My questions are burnt down to two:
Is there a way to clear the caching on specific user controls from the code? If yes, can this be done according to the varyby options?
How would the object caching respond to logged in users or anonymous users using Insert()?
EDIT:
I'm caching multiple things.... And I'm really flabbergasted in which choice to make referring to caching. Can the Cache.Insert be varied by Parameters?
The main problem is peopling editing things from the backend, which needs to trigger an event that reinstantiates or clears all caching items referring that object.
You can remove items from the output cache using the following.
HttpResponse.RemoveOutputCacheItem("/caching/CacheForever.aspx");
Now, this is only going to get you part of what you are looking for. This will remove ALL cache entries for that specific page. The MSDN documentation confirms the behavior.
As to your other question Cache.Insert() is a single cache store across the application, user identity is not considered.
Now I would also take a bigger look at what you are doing, it might make sense to only cache the actual data and then you can add/remove the specific items. However, if your .control really does take a lot of CPU etc to handle the display then the output cache idea works.
Using the System.Web.Caching.Cache class you can cache items and create dependencies for the items in the cache. If you're using a SQL server, then you can use the SqlCacheDependency class to clear items from your cache based on your database.
Otherwise you can create your own derivatives of the CacheDependency class which you can use to accomplish the same thing. I found this post that describes doing that.