Skip to main content

5 Tips and Tricks for Renderings Using Ajax


Eventually a component on a page is going to need to pull in some new information and you don't always want to reload the whole page. Making use of Ajax allows you to avoid a full reload but when you use Ajax with Sitecore there are a few important things to keep in mind:
  1. Make sure you set up your controller to function with the Ajax call.  Are you sending back some data, the whole rendering, or are you just updating something internally? Be ready to handle whatever is coming into or out of the controller. Note that if the Ajax function is posting data you must add [HttpPost] before the controller method.
  2. Regardless of how you get to your controller - there won’t be Sitecore context! Your controller has no idea what the user was doing or where they were on your site when the Ajax call was made. You need to pass all the information in your model to the controller including the data item and anything else relevant for your controller to give context. One way to give context is to output a relevant ID (or the Sitecore Context ID)  somewhere on the page. You can then grab the value via javascript to pass back to the model for when you lose context.
  3. Data can get complicated when passing back and forth between controller and JS - create a model which represents the data you’re working with to keep things clearer. The simplest way to do this is to use strings/integers etc for the fields you need to pass back and forth via JSON. Something like Quicktype.io ( https://app.quicktype.io/ ) can help you quickly generate C# models from your JSON (or other) data to use with the controller on the server side.
  4. Event binding can be lost if content is being reloaded via Ajax depending on how it was bound initially. If you have other javascript tied to any part of the component or page that’s being updated - either make sure that your javascript around those components is bound to something other than itself (such as the body tag), or that you run the js again once the call is complete. Otherwise, you’ll find the js runs once, and then isn’t firing since it was being bound to items that no longer exist.

    For example, some jQuery to bind to body for a click event: 
    An example ajax call:
  5. Don’t load your entire site to test a single controller, use Postman (or something similar) to test out your controller without needing to hit the page! This way, you can make sure your Ajax calls will work with the controller.  https://www.getpostman.com/


Labels:

Comments

  1. UnknownOctober 22, 2018 at 3:40 AM

    This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Using the Source Property

For each of the properties in your template you can set a source for it, this isn’t always used but can improve user experience drastically when done throughout a site. The source field comes in to play whenever you are using any of the following fields: Droplink, Droplist, Droptree, File, Grouped Droplink, Grouped Droplist, Image, Multilist, Treelist, Rich text field and a number of others. There are various ways of setting these up to achieve different results – but in general you are using the source to limit the set of items that can be used, and this requirement can also help you determine what kind of field to use. For example, if you have a Set of items all split down into sub folders and want the content editor to make use of the tree, you could use a TreeList or Drop Tree, but if you just want a set of items without the opportunity to see where those items are – multilists or droplinks are the way to go. For Images you’re generally just specifying where to look for and put th...
38 comments
Read more

Web Forms for Marketers: Send Email

To have the save action for your form actually send email, you will need to change one of the settings, otherwise you will receive this error whenever submitting the form: We experience a technical difficulty while processing your request. Your data may not have been correctly saved. Also in your log (/data/logs/newest log file) you will see this error after the form has been submitted: Exception: System.Net.WebException Message: The remote name could not be resolved: 'example.host' Source: System at System.Net.ServicePoint.GetConnection(PooledStream PooledStream, Object owner, Boolean async, IPAddress& address, Socket& abortSocket, Socket& abortSocket6, Int32 timeout) at System.Net.PooledStream.Activate(Object owningObject, Boolean async, Int32 timeout, GeneralAsyncDelegate asyncCallback) at System.Net.PooledStream.Activate(Object owningObject, GeneralAsyncDelegate asyncCallback) at System.Net.ConnectionPool.GetConnection(Object owningObject, GeneralA...
58 comments
Read more

Determining Page Editor Status with Javascript

     Often you’ll need to know if you are inside or outside the Experience/Page Editor in order perform an action. If you are on the server-side in code-behind you can check the Sitecore.Context.PageMode to determine which mode you are in. But what about at runtime? Javascript per usual can save the day! Though you can find PageModes through the Sitecore object if it is available to the browser, it may not be there. Depending on how things have been set up with your solution, the Sitecore object may not return a null as would be expected when checking to see if you can access it. Instead Sitecore may be undefined.  Contrary to some examples on the web with only null checks, this quick little change in your script can correctly let you know if you are in the page editor: Just take a look to see if isPageEditor is true or false and you’re set!
2 comments
Read more