I have an asp.net application where I have a radGrid control that displays records from a database. I would like the grid control to do client side caching (paging and sorting). However, I can only find one sample (Grid - Client-Side Binding and Caching) on Telerik's website, but it uses a webservice as a Databinding location source.
Has anyone had any experience with radGrid, clientside caching displaying data from a database?
Related
How do I use the signal R when the information in the database has changed the entire page to reload?
Or how can one bind the grid view again?
I recently tried to create an ASP.Net server control. This server control should has at least two pages. One page for registration (Users can register) and one for asking questions. It is important to make it with ASP.Net Server Control.
The plan is to make this server control and web designers can easily drag and drop this server control into ASP.Net WebForms or MVCs and set properties like back-color or header image in properties tab. I wonder if its possible to have two pages in a server control dll file with all events, viewstates and properties.
Please some one tell me how to create a second page in a server control dll file? And another question is how to move between those pages?
As per my understanding you should go for MultiView or ASP:Wizard control ?
Maybe you are looking something like this from codeproject.
I'm a PHP developer who has to work on ASP.net projects and I'm wondering why every page is wrapped in a form. This just doesn't make sense to me.
Also What's with all the hidden input fields especially the "View State" one.
ASP.Net tries to make it so that the programmers can pretend that the web is a stateful platform, and that it behaves like a desktop application. The ViewState is basically a serialized block of the state of the page when it was generated. When the page gets posted back the server side model gets initialized to the values in ViewState, and then the new values from the posted form are applied.
Part of becoming a decent ASP.Net programmer is learning when to use ViewState and not, because the default is to use it everywhere which causes a lot of bloat in the downloaded page.
Every ASP.NET page is wrapped in a <form> element because the entire framework revolves around POST commands.
ASP.NET provides 'web controls' which are object-oriented abstractions of HTML elements (and in some cases, groups of elements) - in your server-side code you can attach commands to various events on web controls (for example, Button.OnClick, TextBox.OnChanged) - the framework wires these up using a combination of hidden fields and generated javascript. The generated javascript typically sets a hidden field few values to indicate (for example) which control triggered the post and the command arguments (if applicable), then submits the form.
ViewState is a technique used by the framework to serialize client state. It's an alternative to using session heavily, trading larger HTML payloads for a lower memory footprint on the server.
Everything in ASP.NET (aspx pages) works off of posting data.
This means that anything you place on the web page with a server-side action will cause a "post back" to itself. The post back contains information such as "what just happened" and some information that helps the web page to maintain state (which web pages don't traditionally do). The view state is part of that task of maintaining state.
If you don't like the way aspx pages try to turn web-pages into forms-style stateful applications, you can try out the ASP.NET MVC framework, which lets the web work as intended!
ASP.NET WebForms engine creates a stateful abstraction over stateless HTTP.
The key object is a server page. Controls fire events that are processed server-side. Controls maintain their states (usually, input values) between requests.
Any time you click a server control, a "postback" request is sent back to the server. ViewState actually contains the data telling the server what control fired the event. That is why there is always a form (and any more forms are not allowed).
If I disable ViewState at Page level, will it be remembered for GridView inside the page?
If you disabled ViewState at the Page level all controls on that page will have ViewState disabled (i.e. won't be able to use any of the functionality provided by ViewState). I'm not sure from your question if you want GridView to have ViewState enabled and all other controls be disabled, but if that's what you want to do then you have two options:
If you are using .NET 4.0 then you can disabled ViewState on the page level and enable it just for the GridView
If you're using .NET version prior to .NET 4.0 then you have to explicitly disable ViewState for all controls (by adding EnableViewState='false' to all elements) and don't add that for GridView. You cannot disable it on Page level and enable for GridView only.
In my last job we ended up rewriting the complete ASP.NET stack (forms, controls, validation, postback handling, ajax library etc...) - the reason I was given was that the ASP.NET controls were not accessible enough, not were any of the third party controls that were assessed for the project.
Can anyone point me to good accessible ASP.NET controls that do ajax as well?
Failing that, how would you approach creating accessible, ajax enabled controls?
You could take a look at the 'App_Browsers' feature in .NET.
It gives you the opportunity to hook into the rendering engine for each control. The original intention for this was to be able to alter the HTML output of controls depending on the user's browser - but you can also do it for all browsers.
You could also take a look at these control adapters, which make the normal ASP.NET controls 'CSS Friendly'.