I have an application that makes a series of WCF calls that return JSON via JSONP. In turn javascript code will then bind that returned data to HTML controls.
When a bot / spider hits my application, no data would be indexed because javascript would not execute in the bot.
What are some good patterns for dealing with this problem? Ideally I'd like to not have to maintain two sets of data-binding code (one on the server side and one on the client side).
Essentially I need the resulting data to come downstream. Some ideas I had were to.
1) link RSS/ATOM equivalent data
2) a backdoor HTML page
3) an HTML renderer that can execute an ASPX page server side ahead of time and then pass that off to the client
Any guidance would be helpful
Option 3 can I think solve the problem, I will suggest to try this:
Try to see if javascript is enable/bot is browsing the page or not
If it is bot or js is disabled, load the page without web service call and render it with server side code
otherwise go for js version.
I will recommend this if your data is relatively low and the implementation cost is not too high.
Related
I saw couple of similar question here on StackOverFlow but none of them to summarize with the following criteria.
What are the advantages of jquery.ajax vs UpdatePanel (like - viewstate, speed, size)?
IMO, comparing jquery ajax to update panel is a bit like comparing apples vs oranges.
UpdatePanel is very easy to use; you really don't have to write any significant code to achieve AJAX, works seamlessly with server controls model. This is achieved by issuing asynchronous post request - so all form elements get posted including view-state. On server side, entire control tree gets loaded and page follows normal life cycle till rendering at which only html from update panel is sent (along with view-state) to client side. So you have large request size, more server load and large response size.
Alternative is to make async server calls, where request would carry only data that is needed for server call. The server would respond with the data needed. Typically, one would use JSON to transfer data to/from server, reducing request and response size. On server side, typically, a script service or page method is used which will do the specific task (as opposed to following a page life cycle) reducing server load.
Now, script services/page methods can be either invoked using proxies generated by ScriptManager or using jquery AJAX. I prefer jquery to avoid the larger size of proxy code generated by ASP.NET AJAX.
For me the biggest disadvantage of the UpdatePanel is the generated HTML output. Just give it a try and have a look at your HTML I think it isn't as readable and small as it could be.
On the other site the entire Microsoft Ajax Lib has been discontinued.
The drawbacks of Update panel is Why ASP.NET AJAX UpdatePanels are dangerous
I'm dipping my toes into web development. Based on various bits of advice, I'm going to start by getting a handle on html, css and javascript.
I'm interested in Ajax, I've had a look at the client side code and that looks straight forward enough, I'm slightly confused about what I do on the server side.
I'm using IIS and ASP.NET. I've had a google but I can't find anything that is either simple or current. There's a lot of talk about the Ajax toolkit, which I believe are controls which use Ajax (and may be retired??) Everything else seems to be based on old versions which I don't trust.
So, in really simple terms, what do I have to do in IIS to respond to an AJAX call?
Quick aside, I believe we can use JSON for object serialisation?? I assume I don't need to in the interests of getting a simple sample running?
So I have an Ajax call which will have one parameter, and I want to return "something" based on the parameter. What is the simplest code to achieve that with IIS and ASP.NET?
Thanks
An AJAX call is basically just a regular call to your website. The only difference is how the browser handles it - AJAX calls are done in the background with Javascript (the J in AJAX) and then does something with the data. You could take the URL that you're doing an AJAX call with and put it in your address bar and it'll return the exact same data. So, basically, what you do on the server side is exactly what you would do as if it were a form being submitted, for example.
As far as object serialization, yes, JSON can do that.
First of all, doing ajax has nothing to do with IIS; it has to do with ASP.NET.
There are essentially 2 ways to do AJAX in .net
1) Heavy use of the framework. You can put your asp controls (such as literals, gridviews, listbox...) in a control called an updatepanel. For this to work, you need to add a script manager to the aspx page. Then, when the user raises an event (for example, paging and sorting of a table), the request is handled by the framework and only the part of the page that's in the updatepanel is refreshed. The other way to raise events is by using the __doPostback function that comes with the asp.net framework. The downside of this method is that a lot of data needs to go back and forth between the user and the server so it can be slow. The upside is that you don't have to worry about generating the HTML since the asp controls handle it for you.
2) Heavy use of Json. With this method, you can use jQuery to call a page method or a web service. You send a json object to the server and you get a json object back. With jQuery, this is really easy. The downside of this method is that you're getting just the json data back: no formatted HTML. So, if you're looking to have a table updated, this method would be tedious because you'd have to recreate the entire HTML. However, the upside of the method is that it's very fast because only the raw data is transmitted. If you implement a web service, you don't even need to create an entire page.
What do you need to get from the server?
If you want to return "something" from the server that's "simple" (just data), I'd recommend a web service with jquery to trigger the call. If the return data is "complex" (html code for controls) then I'd recommend using MS ajax with the update panel.
Don't use the AJAX Control Toolkit, ASP.NET AJAX library, updatepanels or the scriptmanager control. Microsoft have pretty much ditched the lot in favour of jQuery and its Plugins (sensibly).
Here are just some of the ways you can use AJAX with jQuery in ASP.NET: Many ways to communicate with your database using jQuery AJAX and ASP.NET
I am doing some grid work just like a stock exchange application which will have good data volume and page should be automatically refresh after some mentioned time say 1 min or 30 sec without being post back.
What is best way to do this ? Should I use grid with ajax or grid with ajax and web service should be used ? If possible please refer me some article or link on implementation of your suggestion.
You can use an UpdatePanel (place the grid inside the panel) and maybe have a JavaScript timer to update the panel periodically.
Alternatively you can have a straight HTML table and periodically call a webservice and update the table from the client side. I think you would get slightly better performance but there is a bit more work involved.
A webservice call from JavaScript will not cause a postback. When calling a webservice you might get better performance because you are only getting data instead of formatted HTML. However, you will probably return the data in XML or Json format, so there will be an overhead (Json will be better in that respect).
If you know that only a small portion of values are going to change between two refreshes, then you will get better performance by only returning the values that have changed.
If you're not very experienced with JavaScript then I would suggest that you use a library such as jQuery. You may read the following resources for implementation details:
Calling an ASP.NET webservice with jQuery
Updating an HTML table from Json data using jQuery
Depending how experienced you are with webservices, Json and jQuery, it may not be an easy task. The UpdatePanel option is definitely easier to implement.
Why do I need script on an aspx page?
Javascript will allow you to perfrorm client side coding, so to avoid having to post back to the server.
From Using JavaScript Along with ASP.NET
Working logic and application
processes on the client-side allows
browser based applications to seem
more responsive and to have more
"snappiness" to them.
For client scripting, i.e. validation. There are many scenarios where you need to execute certain logic on the browser's end.
Javascript runs on the client side. So if you want anything to happen or change without refreshing the whole page you use javascript.
There are a lot of things the server can't really do that well. For example if you want to manipulate the page. You could post the whole thing back to the server with some sort of action and get the server to give you a new page. Or you could just use javascript to change it for you and avoid the trip to the server. It is faster for the client and takes the load off of your server.
It helps in doing things on the client side, which essentially means you can :
reduce burden on your server
by doing less postbacks.
do a round of validations on the client
side itself if they are non critical.
Do some fancy stuff like animations etc with out contacting the server
There are a lot more implications/uses of using JavaScript.
For knowing more, remember google is your friend!
Thanks
I'm not sure if you mean why ASP.NET pages requires Javascript, or if you mean additional scripts on the page.
ASP.NET uses Javascript for several types of postbacks. If you for example have a LinkButton, a script is making a postback instead of the default action of the link.
You can use additional scripts on the page for visual effects and to verify data before doing a postback to prevent unneccessary postbacks. (Of course you should also verify the data on the server side to protect against malicious actions.)
Let's consider that I have an asp.net page which will go to the server after a client-side event and will do "some stuff" and show a return value of this process on the UI afterwords.
My question is, if I am working in the same domain, how should I decide between creating a web-service and calling that AND simply raising a post-back and handle this "some stuff" on the aspx page itself?
Under what conditions creating a web-service becomes meaningful to overcome some processes while working in the same domain?
There are no hard-and-fast rules. However, I can offer a few high-level guidelines:
Prefer an .aspx page if the result includes a significant amount of markup (HTML, JS, etc), or where generating the results is simplified by having access to control state from the original page. Keep in mind that the Page object carries a significant amount of overhead with it.
Prefer a web service for queries that can be parameterized and that return structured data
Prefer an HttpHandler for queries with simple parameters that return either simple, full-custom text or binary (such as an image)
I would look at how fast it takes for the post and reload action to occur. It depends on the user's expectations. Most people, if they know they are using a browser, will find that up to two seconds is just about acceptable for the action to occur, and the screen to be reloaded. On the other hand, in one of my jobs, I was using ASP.NET to drive a touchscreen, and this just looked totally wrong, so I refactored the code to use a static web page plus a WebService component.
You also need to take into account the capabilities of the browser. In the example above, I knew that I was only using IE6, so I could afford to write my Javascript code to take advantage of that browser. You may not be so lucky. If you are to use a web service which has client update, you should ensure that you target a version of Javascript and DOM that is supported by all your target browsers.