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.
Related
I am looking into utilizing Google Maps API to do some geocoding. I want to implement client side geocoding, to remove the possibility of request limitation.
I need to do some fairly complex logic on the result set, and I would prefer to do that in C# as it is a ASP.NET MVC application. However part of that logic is possibly makeing subsequent follow up requests and that again would require JavaScript.
So, my first thought is to make a service in my application to pass JSON results to and certain return types to trigger the subsequent request. That seems a little convoluted and want to know from the community if this seems like the best approach and if there are any libraries/third party tools that can help handle this situation.
I've an app that does something similar, with the complexity somewhat decoupled by using standardized events (within this app, not a W3 standard or anything)
Client uses native geolocation, SimpleGeo and Google Loader to guess where the user is and AJAX's that to the server.
Server uses client data, MaxMind, and user preferences to decide where to treat the user as being.
Server response is generic event data (as JSON response) that is converted by a generic AJAX response handler into one or more events triggered against the body element.
Depending on the page, various listeners are bound to the events and or namespaces (see jQuery namespaced events) and they handle the updated location events, e.g., getting different weather data, changing local search results
Some of those listeners in turn trigger other AJAX requests, the responses to those may also carry generic events to triggered...
This way there's no sequential code I have to write, i.e., I can add or remove behaviors (simple or complex) without changing anything else. jQuery Events are all I use, really nothing much to it after you decide how you'll pattern things.
Let me know if that's interesting to you and you want me to expand or clarify a part of it.
You may want to try this API:
http://code.google.com/apis/maps/documentation/geocoding/
It's far more REST like - no Javascript required. May work better with C#
In the end I found the best solution was to do as I stated in my question. Pass the JSON object to controller, do work, then return. Worked pretty well.
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.
For an MVC 2 app that relies on many partial views and almost exclusively uses Ajax for POSTs/GETs, what would be the best way to implement the setting, passing, retrieval and display (using a JavaScript modal) of these messages?
My forms all POST (by way of jQuery $.ajax) to actions that return partial views (html) that are used to update a in the "success:" part of the $.ajax function.
I was hoping for some sort of mechanism in the master view that could "listen" for any messages that any of these partial views might be "delivering"--through their ViewData, for instance.
Thanks.
Edit:
After lots more searching, I found similar people trying to achieve the same thing as me, but none of the questions had a good answer. This one states the question best.
Your "master view" wouldn't be able to have a mechanism like what you're thinking of simply because you're asking it to be aware of potential data that could be given to it based on a possible user interaction.
What I think #cottsak is trying to say is to have delegate functions in your JS code that handle error and success events. Thus you can have 100 Ajax requests but only 2 functions actually handling the response. Within these functions you'll have to normalize the way you deal with the responses so that you don't have to write conditionals for specific forms for example. This might require normalizing your forms to have identical structures and base functionality and differ only on their input content.
For example I use "Wizards" in some of my sites that deal with modal forms:
<div class="Wizard">
<form>
<!-- Any and all possible content -->
</form>
</div>
All my forms of course differ on the actual inputs they have, but they're all normalized in the sense that there's dedicated elements in them for messaging and such. Every single form however is controlled by the same JS with a few exceptions for special scenarios.
You should take a look at the Dropbox web interface. Get yourself a free account and use the interface for 10 mins - copy, move, delete a file. The messaging and validation system is great. And it's largely ajax on their site too. Perfect example of the user experience you want it sounds like.
As for the technical implementation, i have been thinking about this for some time:
I'd use a broker system on the client for which all page ajax requests go through. This way all responses can be collated within a single function (/object, however you design it) and thus the responses too. It's obviously the responses that are key so that Error messages and Status messages can be handled in the same place and rendered to the user in a uniform way.
Server side it wouldn't be too hard. I'd suggest that you have a graceful degradation solution to those actions that return JSON or other ajax responses, in that they can function (and return Error/Status messages) without the client having JavaScript enabled.
I need to generate a block of HTML for use by an asynchronous operation triggered by an HTTP request (I am calling the Facebook API in response to an HTTP request, with the HTML block as a parameter). I already have an .aspx page that generates the HTML required, and would like to reuse that code.
I see three options, none of which I want to do:
Re-write the functionality currently in the .aspx page into a .NET function that returns the HTML. I don't want to spend the time re-writing it unless absolutely necessary. Also, the .NET code to produce the HTML will be much less maintainable than the .aspx markup to do so (yes, even with XML literals).
When I need the block of HTML, make an HTTP request to the .aspx page on the local server. The inefficiency of this does not concern me, but the design compromise does. Because of how the application is structured, I would have to litter my .aspx code with:
if(localRequest)
{doOneThing();}
else
{doTheOtherThing();}
which I don't want to do.
Create an ASP.NET application host to spit out these chunks of HTML. I'd imagine that this would improve on the efficiency of 2, but not the complexity.
Are there other alternatives? The ideal would be instantiating the .aspx page class and executing it with a mocked up HttpRequest or HttpContext. Can this be done, and is it worth the hassle?
There are two related but distinct parts to this problem:
a) how do you ensure that an asynchronous operation has a valid HttpContext?
b) how can you get the HTML output of an ASPX execution returned as a string?
For (a), it depends on how you're invoking the async operation. Unfortunately, in .NET there are quite a few ways to do async operations. But if you want to propagate HttpContext to the async code, there's only one good option: the Event-based Asynchronous Pattern. Although IMHO the event-based async pattern has some drawbacks (e.g. no "wait" operations, hard to sync multiple threads, need to refactor your code, etc.) it does a really cool thing of integrating cleanly with ASP.NET async pages and ensuring that the right context is set up when your callback gets control.
So in other words, propagating context only works (without doing a lot of extra work, that is) if you're playing by the rules set up for ASP.NET Async Pages. Here's an article on async pages if you're not familiar. Here's another post that is useful. In a nutshell, you split page processing into three stages:
1) set up for long-running operations
2) kick off long-running operations (e.g. to get your expensive data)
3) ASP.NET will call your Page_PreRenderComplete handler once all long-running operations are complete. from here, you can bind your data and render your HTML.
What may make this hard is that often you'll need to re-factor existing code since you need to segregate fetching the data from binding the data.
Now, on to (b) above: once you have context, the other question is how to get your page output into a string. There are a few ways to do this too, but perhaps the easiest is to encapsulate the stuff you want to output into a user control (.ASCX) and then follow the instructions in this blog post: http://stevesmithblog.com/blog/render-control-as-string/. See this post if you need data binding too.
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.