I am relatively new to ServiceNow, and I am building some UI pages where I basically do not need any of the SN structure except for Glide Ajax (I need to get data from a Script Include).
The problem is that when I select "Direct" the Glide Ajax functions are not available any more in the client script.
Does anybody know if this is possible to achieve? I searched everywhere without success.
Thanks a lot!
If you check "Direct", it omits all ServiceNow specific JavaScript and CSS. "GlideAjax" is ServiceNow specific JavaScript.
If the data that you are pulling back from the Script Include is static (meaning that you can pull it when the UI page is loaded) then you can probably do it inside an "evaluate" block in the HTML section of the UI page. You could have your Script Include return a JSON object as a string and store it in a variable. Then you could have your client JavaScript parse that variable. I am not a Jelly expert, so I would be curious to know if it works.
Related
I have a project where we're using an iframe. However, project specs have changed and we can no longer use the iframe. Instead we need to request the html page in the background and display it on page when loaded.
Any ideas on how to do this via Ruby (rails). Thought best to ask for general direction before diving in.
Thanks!
load it with ajax, and do a body append
It depends on where you want to have the work occur, on the back-end in your Rails code, or in the user's browser via JavaScript, as #stunaz suggests.
Keeping it in the browser and loading via JavaScript will expose the HTML page's location to the user, which might not be desirable. Loading it from the back-end and including it in the HTML emitted to the browser will hide the source entirely.
If you want to do it on the back-end, the simplest thing is to either load the file from the local drive, if it is local using File.read. If it's on a different machine, you can use Open::URI to pull it in. Either way, you'd then insert it into the HTML in the right spot. How you do that depends on what you are using to generate the outgoing HTML.
I'm working on a website that uses AJAX to retrieve data from the server and display it on the page. Django renders the initial page content using its template engine (so it will be indexed by search engines). When the user takes an action, jQuery fetches the new data via AJAX and the response is returned as JSON. I would like to have jQuery render this new content without violating the DRY Principle. Therefore I would like to use a templating engine that is "shared" between Django and jQuery. I've been running in circles trying to find the best solution but always seem to run into a road block.
Has this already been done? Here are the options I have thought of:
Use regular expressions to transform the Django template into correct jQuery template syntax, and render it in its raw form to the page. jQuery will then pick it up and use it to render the new data.
Extend the jQuery template engine to recognize the Django template syntax, again rendering the raw Django template to the page for jQuery to use.
Has this been successfully done before? Either way seems like a lot of work for anything but the simplest of Django templates because of the plethora of Django tags and filters that would need accounted for.
Your best bet is to pick a template language that has both Javascript and Python support, and use that everywhere.
As far as I know, Mustache is your best bet.
I haven't found a perfect solution since I asked this question, but for the sake of development time I resorted to sending back both JSON and HTML in the AJAX response. This way the django templates still perform the HTML generation, but javascript is still free to utilize the data without having to parse the HTML.
I am sending approximately twice the data over the network, but I'm going to live with it until my application grows to the point where a smaller response is beneficial. At that point I will probably look into something like Mustache as Rob mentioned.
We're currently doing a project that accepts user-provided html and has our own injected into it. This perfectly matches Play's abilities. However, I am at a loss as to how to use dynamic content as a view template without manual intervention. It seemed best to use a blob to store the information (given that there could be thousands of templates) and somehow load that way.
Any suggestions?
Thanks in advance.
If you really want to do this (I’m not convinced this is a good idea), have a look at the implementation of play.mvc.Controller.renderTemplate(String, Map<String,Object>) in the Play source, to see code that loads a template, binds variables and renders the template.
I have a page on my site which has a list of things which gets updated frequently. This list is created by calling the server via jsonp, getting json back and transforming it into html. Fast and slick.
Unfortunately, Google isn't able to index it. After reading up on how to get this done according to Google's AJAX crawling guide, I am bit confused and need some clarification and confirmation:
The ajax pages need to be implement the rules only, right?
I currently have a rest url like
[site]/base/junkets/browse.aspx?page=1&rows=18&sidx=ScoreAll&sord=desc&callback=jsonp1295964163067
this would need to become something like:
[site]/base/junkets/browse.aspx#page=1&rows=18&sidx=ScoreAll&sord=desc&callback=jsonp1295964163067
And when google calls it like this
[site]/base/junkets/browse.aspx#!page=1&rows=18&sidx=ScoreAll&sord=desc&callback=jsonp1295964163067
I would have to deliver the html snapshot.
Why replace the ? with # ?
Creating html snapshots seems very cumbersome. Would it suffice to just serve simple links? In my case I would be happy if google would only index the things pages.
It looks like you've misunderstood the AJAX crawling guide. The #! notation is to be used on links to the page your AJAX application lives within, not on the URL of the service your appliction makes calls to. For example, if I access your app by going to example.com/app/, then you'd make page crawlable by instead linking to example.com/app/#!page=1.
Now when Googlebot sees that URL in a link, instead of going to example.com/app/#!page=1 – which means issuing a request for example.com/app/ (recall that the hash is never sent to the server) – it will request example.com/app/?_escaped_fragment_=page=1. If _escaped_fragment_ is present in a request, you know to return the static HTML version of your content.
Why is all of this necessary? Googlebot does not execute script (nor does it know how to index your JSON objects), so it has no way of knowing what ends up in front of your users after your scripts run and content is loaded. So, your server has to do the heavy lifting of producing a HTML version of what your users ultimately see in the AJAXy version.
So what are your next steps?
First, either change the links pointing to your application to include #!page=1 (or whatever), or add <meta name="fragment" content="!"> to your app's HTML. (See item 3 of the AJAX crawling guide.)
When the user changes pages (if this is applicable), you should also update the hash to reflect the current page. You could simply set location.hash='#!page=n';, but I'd recommend using the excellent jQuery BBQ plugin to help you manage the page's hash. (This way, you can listen to changes to the hash if the user manually changes it in the address bar.) Caveat: the currently released version of BBQ (1.2.1) does not support AJAX crawlable URLs, but the most recent version in the Git master (1.3pre) does, so you'll need to grab it here. Then, just set the AJAX crawlable option:
$.param.fragment.ajaxCrawlable(true);
Second, you'll have to add some server-side logic to example.com/app/ to detect the presence of _escaped_fragment_ in the query string, and return a static HTML version of the page if it's there. This is where Google's guidance on creating HTML snapshots might be helpful. It sounds like you might want to pursue option 3. You could also modify your service to output HTML in addition to JSON.
I've more or less given up on this. There really seems no alternative to generating the html on the server and delivering it in the html bdoy if you want goolge to index your directory.
I even tried adding a section wraped a .net user control which implemented a simple html version of the directory. But google also managed to ignore ..
So in the end my directory has been de-ajaxified. :(
I need to create a portable script to give to others to implement on their websites that will dynamically show content from my database (MySQL).
I know AJAX has a cross-site problem, but it seems that Google's ad's somehow manage the effect in a cross-browser / cross-site fashion.
Knowing that I have to give people a simple cut/paste snippet to put in their website...how can I achieve this? How did Google?
They use an <iframe>, so the ad is served from their server, and can talk to their database. I'm not actually sure that they use any sort of AJAX from their ads, though; they appear to just be mostly static content, with a few scripts for tweaking the formatting (which are optional, since they want their ads to be visible even if users have JS turned off).
Remember, you can always look into this on your own, and see what they did. On Firefox, use Firebug to explore the html, css, and scripts on a site. On WebKit based browsers (Safari, Chrome, and others), you can use the Web Inspector.
Google's ad code is loaded via a script tag that calls a remote javascript file. The AJAX restrictions that are generally enforced with xmlhttp, iframe, and similar AJAX requests don't apply when it comes to loading remote javascript files.
Once you've loaded the javascript file, you can create iframes in your page that link back to the actual hosted content on your server (and feed them any data about the current page that you wish).
jQuery has built in support for jsonp in their ajax calls. You may want to lookin in to using that if you are really needing to use ajax.
http://api.jquery.com/
http://docs.jquery.com/Ajax
You don't need iFrames and you don't need AJAX. It's really, really simple!
You pull in a remote JS file that is actually a constructed file from php/asp/whatever. In your JS file you have a document.write script that writes the content. It's that simple.
We do this all the time with media stored on separate sites. Here's an example.
YOUR SERVER: file.php (which outputs js)
<script>
document.write("I'm on a remote server");
</script>
OTHER SITE:
<script src='http://www.yourserver.com/file.php'></script>
And it will output the content generated by the script. To make the content customized you can put in script vars above the script call that will adjust what your file pulls out. From there it's pretty straightforward.
I realize this question is a year old, but I've written a library that can help with the document.write part of the problem (whether this is a TOS violation, I don't know) writeCapture.js. It's pretty simple:
$('#ads').writeCapture().html('<script src="whatever-your-adsense-code-is"> </script>');
The example uses jQuery, but you can use it standalone as well.