I want to use autocomplete in a aspx form. Requriment is autocmplete should first check for data on local (common data will be loaded with page in javascript array). If not found than it should request the server database and search the data there.
There are many plugins, scripts and widgets avaialable. Please guide me which is best and easy to use in .aspx and also that works on both ends (first it should check on client and if not found then it should go to server).
How much data are you caching in a JS array? We use Telerik controls to do AutoComplete and haven't had any problems with performance using an AJAX/WebService call to populate the list.
I'm sure you can achieve the same results with a free or homegrown solution as well. I'm just wondering if it's worth creating both a client and server side model for this.
Related
I'm developing a web-site with ASP.NET 4.0. Some pages need to get data from the server via AJAX requests (for instance, a list of items, sorted or/and filtered by a parameter). And there I can see two options for templating:
1) AJAX handler get data from database and templates it with Mustache. Returns html code ready to display to the end user.
2) AJAX handler get data from database and sends it as JSON. Javascript code formats data with Mustache on the client-side.
My question is what will perform faster?
I don't think your question can be answered without testing, but I'm not sure the difference would be really significant. However, raw speed notwithstanding, I would go probably for option 2:
HTTP traffic will certainly be lighter with your JSON-formatted data rather than a complete HTML output (this is generally better),
The data can still be handled dynamically on the client side
If your website is designed as a "web application", with an emphasis on client-side processing, this is the way to go. But on the other hand, if you think of your output as something mainly static, it is probably simpler to keep all the work on the server side.
I've read tons of sites on this. There are many "Examples" if you call some code with no explanation of how it was generated (design view vs typed) an example or just want to use simple select and update statements.
I have a Gridview. I am populating it using code from a stored proc. Now I want to edit the data. I have nothing set in the properties of the Gridview through design view (datasource, columns, etc.) My question is, how can I set this to allow editing and use a SP to send it back to the database?
Do I have to now manually create columns with code since I chose to not set properties in the design view?
Is it better to set the properties in design view and go that route? I started that way, but had problems when it came to updating with a SP.
I guess the whole do it in the designer vs do it in code thing has me confused.
I started adding RowEdit, RowCommand, etc. to the html and c#, but still don't see the EDIT/CANCEL on the webpage when I run it.
Learn to use the ObjectDataSource. It gives you maximum freedom of what way of storing the data you use - you delegate the select, update and delete to an external class where you just write your code which uses ado, linq, hibernate, a webservice or just anything.
Coding your views directly against fixed database structure would hurt you sooner or later.
I have this textbox in asp.net webform page used to enter a city. On entering some text it provides suggestions just like facebook does of matching results.
I tried these two methods to implement this.
I first used onTextChanged event and AJAX and found out it only works when the textbox loses focus. I wanted a solution to work as you type. Advantage of using this was that I could use a database and it would be fast, because no xml files will be transferred in the process.
2.I used ajax, clientside using js. But the problem is the xml containing cities, there states, country is a massive 30MB file. So, it was impossible to use it, so thought of making 26 small xml files of each alphabet out of that big one but still they would be big enough to actually use. So, now I am planning to use 26*26 files containing the cities with same first two alphabets but I think its ineffective way to do what I want.
Is there any other efficient way of accomplishing it?
The best way would be to use a database, if I could.
You need to use onkeypress and/or onkeyup events instead.
Did you know that there are plug-and-play auto-complete components out there that are free? For example http://jqueryui.com/demos/autocomplete/
Use JSON! It's much more compact. You'll probably save 30-40% on the size of that data.
Did you know that you don't need to pass the whole data set for that to work? You can have it live on the server (e.g. in the database, or cached on the webserver for faster access and less db traffic), and have clients only pull small set of data at a time, based on characters that they type. That JQuery UI AutoComplete supports that feature.
If you cannot use JQuery and JQuery UI (not wanting would be an unacceptable answer), then I'm pretty sure there are other free alternatives, including this one: http://www.asp.net/ajaxLibrary/AjaxControlToolkitSampleSite/AutoComplete/AutoComplete.aspx
I've received a project for internal use. My application has to store about 100 rows of meta data of a game and each row has about 15 fields maximum. Fields can be game name, game category, maker, source code path, etc. I will most likely have to join about 5-10 tables for each row of record. Only a few people are using it and will receive very little hits. Speed performance is not a much of an issue. The rows of data I have to present must be sortable and searchable
My current solution is to use ASP.NET's GridView control with ASP.NET's AJAX UpdatePanel to give it that ajax feel. I'm thinking of using LINQ-to-SQL as my data access layer. I'm thinking of building my own custom search engine but if there's an existing control that has this feature already, i would prefer to use that; anyone know of such control exist? Anyways what do you guys think?
Update #1:
I'm looking into creating a DynamicData website. Any have thoughts on that?
Use ext.js!
Look at the Grid Samples, its a very shallow learning curve and provides you with amazing results in little to no time.
http://extjs.com/products/extjs/
Basically, you expose your data via a web service (asmx or WCF, your choice), throw the Ext.Js grid onto your html/aspx page and point it at your webservice. Configure the control for things like sorting/searching/expanding/grouping/paging etc (use the api reference http://extjs.com/deploy/dev/docs/).
ASP.NET Dynamic Data looks really cool, particularly for sites where you've got:
lots of data
not a lot of worries about performance
no / little desire to skin / design the site
no / little desire to extend existing / write new functionality.
So I'd say that's a good match for your project.
Gridview is your best bet. It's so powerful if you know how to use it correctly. It does automatic sorting and if you can code pretty well you can get the data to be filterable(if that's a word). It also makes the Connection to the database for you....so in my opinion, you can't beat the gridview when it comes to reports like that.
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.