This might be a stupid or obvious question, but our whole site is rendered using XSLT to transform xml which is created on the fly from database queries and other pieces. Im starting to push a lot of ajax into the site to make it more dynamic, is there a good tutorial on xslt and ajax?
Are you using XSLT on the server or in the browsers?
Modern browsers now have support for XML transformations from within the browser, one way is using AJAX to fetch the XML along with its stylesheet. You can then offload the processing of stylesheets to the clients machines. Be sure to cache the stylesheet and perhaps even send compressed XML.
The coding should be straight forward if you already know how to do AJAX. I worked on a system like this 5 years ago and it is a viable way to go.
I would definetly agree with a previous commentor who shuddered at the thought of XSLT doing your heavy lifting. That is not going to be all that performant. Don't get me wrong, I like XSL a lot, but ...
Not as much of a tutorial, but the folks at Mulberry Tech (no idea what they do, or who they are) maintain a series of Quick Reference Guides for XSLT (and plenty others) that I find invaluable.
http://www.mulberrytech.com/quickref/
hope this helps...
I think most of the answers are missing what the OP is asking for. I think the OP is asking if there is a way to get the XSLT generated HTML using AJAX.
I am taking this approach on Umbraco.
Create the XSLT Macro that generates the HTML
Place the XSLT Macro in a blank page
Call page with AJAX
Replace the existing HTML content
our whole site is rendered using XSLT to transform xml
That thought makes me shudder. I've worked on two sites that have used XSLT to do heavy lifting in dynamically producing frequently accessed pages, and in both cases it required more development effort and CPU time per access than it was worth.
Irregardless, www.w3schools.com has plenty of good tutorials on many web technologies. They even have tests.
If you want to do AJAX while maintaining support for multiple web browsers I would strongly recommend that you check out: JQuery, Prototype, and Dojo
I think JQuery is the best but I will leave that determination up to you.
I've used this technique extensively, both on client and server side. My experience has been that it performs adequately in most scenarios (but then I'm contrasting its server-side performance with VBScript in ASP pages).
Where performance is an issue, it's very important to take XML parsing and XSLT compilation out of the operation wherever possible. If you have a client-side method that uses XSLT to dynamically render an element in the page, make sure it's not loading and compiling the XSLT every time it's called. If you're using server-side XSLT, cache the XSLT processor object in whatever collection your server environment supports.
You can get significantly better client-side performance by using Javascript and JSON instead of XML and XSLT. I haven't benchmarked it, but I'd bet that the biggest performance gain comes out of the fact that parsing JSON is much less CPU-intensive than parsing XML.
Try using tox as an example. There isn't a tutorial, but if you take a look at the example provided, it is well commented and includes AJAX.
Related
I have heard about AJAX for years but I never felt the need or the intrest on learning it, I knew it was a mix of Javascript and XML but I never took the time to actully try to understand it, until now.
This is what I currently understand about AJAX. Ajax is not a language, it is just a combination of existing technologies, basically JavaScript and XML (and possibly HTML and CSS) and uses the XMLHttpRequest to comunicate with the server in the background to update/load only parts of a page instead of reloading the whole page.
Things I don't fully understand.
1- Is there any AJAX documentation or API that I can refer to to see what functions/options AJAX offers?
2- Why every book in Amazon seem to be old? Is this because AJAX this is not a language and doesn't change?
3- I read the tutorial at www.w3schools.com and I was wondering if what is shown in this tutorial is basically all AJAX can do, basically, Request and respoind to a server?
Again, all I'm trying to understand here is basically how much of a learning I still need to go through in order to have a better understanding about AJAX.
Thanks a lot
Long story short: AJAX lets you make calls to the server without submitting a form or navigating the page. That is all it does.
Originally it stood for "Asynchronous Javascript And XML" because the XMLHttpRequest object was designed to receive updates in XML format. Microsoft added the object so that the Outlook Web interface could pop up new mail alerts by polling the server.
Since then, most programmers have eschewed the use of XML as the data exchange protocol and rely on JSON instead. JSON is far easier to parse and work with.
While I could go through some examples of the low level XMLHttpRequest interactions, other sources have that well covered.
Instead, I'm going to give you a bit of advice. Study Javascript and consider learning the jQuery API. JQuery forces functional programming and makes common activities like AJAX calls super-simple to accomplish. You'll learn to be a better Javascript programmer because of it and will hopefully learn to make your sites more interactive thanks to the power that background server requests bring to the table.
Although the 'X' in AJAX stands for XML, applications today are more likely to use JSON encoding over XML as the return data can be evaluated directly by the browsers JavaScript interpreter. The core enabling JavaScript object is XMLHttpRequest which was originally developed as an ActiveX component for IE 5. It has since become a standard object in all web browser implementations. You can read about the core functionality here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest.
Your best bet would be to research modern JavaScript frameworks such as jQuery. http://www.jquery.com/ for information on how to use AJAX technology within your web applications.
This is a bit of a vague question, and likely to get some down votes, but I think it's specific enough that it does warrant some information.
In a nutshell, AJAX is a why for JavaScript to request information asynchronously. The XML portion is a bit of a misnomer, since you don't have to explicitly deal with XML at all. Frequently, you'll use AJAX requests to read in JSON information (since it's so easy to parse and use).
AJAX isn't really a language, or even a framework. It's a technique. It is made possible by the XMLHttpRequest class, along with some related technologies. Since it isn't 100% consistent across all browsers, it is usually best to use a third-party library. jQuery and most other larger frameworks usually have it built in. You can also find some small AJAX-only libraries, like this XMLHttpRequest project on Github.
Every book on the technique is probably old because nothing has really changed substantially since the technique starting becoming popular. I've been using it for at least the past 3-5 years, and not much has changed (other than a bit more standardization in modern browsers).
The respond and request is basically all AJAX can do. However, that enables a whole world of possibilities. Long story short, it's a way to communicate with the server without having to refresh the page, allowing for much smoother UI and UX.
The simplest way to think about it is that it lets you fetch data without a page reload.
Think about how Google Maps loads in bits of the map as you drag around - it clearly doesn't load the map for the whole world.
In older map sites you clicked a left, right, up or down arrow, the page reloaded and the new data was shown.
AJAX lets you make pages feel much faster and smoother.
Technically JSON is usually used instead of XML as it's more Javascripty than XML.
Most sites likely use it somewhere or other, ranging from loading sidebar widgets after the main content, to the whole app, like Gmail.
Given a really large, 3+ gig, binary file is there anyway that I could stream, from client to server, only portions of the file using JavaScript given that I know what byte range of the file that I want to receive?
I have a Ruby on Rails application that needs to grab specific portions of a file from the client. As one user has stated I could do this using Java.
Edit: After some reading it appears that HTML5 via slicing a file may be the best bet. http://www.html5rocks.com/en/tutorials/file/dndfiles/
The basic answer is yes, assuming your web server supports it (which many do).
You can use the Range HTTP header to request only a part of the file (e.g. Range: bytes=1000-2000). Whether this works for you depends heavily on what you’re trying to accomplish — more information would help.
See this answer for a discussion on using it.
No, not really (at least not now, anyways). The file handling capabilities exposed to Javascript is not powerful enough to really do anything useful client-side when processing files to send back to the server (including things like only take part of a file). There are proposed w3c specs for better client-side file handling for javascript, but none of the major browsers implement it to a sufficient level to really handle this case quite yet.
I'm currently working on a project with similar needs, and the only options we found when we looked into this was to either use Flash, or to use Java. Since we are much more comfortable with Java than flash, we went that route.
We are currently using Groovy and the Griffon framework, as well as Grails for the server-side pieces. Griffon has been great because it frees us from the hassles of desktop vs. webstart vs. applet, and since it's built on Groovy, it can leverage the Swing DSLs so it is much less painless to write Swing.
This question pertains to web applications. I have very little web app development experience, so might be missing some very obvious points/issues. Please point them out.
As I understand, in most web applications, a web server sends HTML over the wire to a client (browser). This happens every time a HTTP request is made. I feel this is very wasteful of bandwidth.
1) Since browsers can run JavaScript, why don't we just send a JavaScript program which can generate the webpage's HTML content (which the browser then renders).
2) Further a browser might cache the JavaScript program and next time the server only need send the data. The protocol might involve the browser sending the "program version" it has.
Consider an example of a relatively simple website Hacker News [http://news.ycombinator.com]. Let us separate the data (30 posts + their metadata) from its presentation. Assuming 1) above, the server can just send the data (say in JSON) + a JavaScript program to generate HTML. This gist shows the idea. The data for the 30 posts is in JSON [http://www.json.org/js.html] format. For this particular example the data transferred is cut in 1/2 (size of data+JavaScript / size of HTML). Further if browsers can do 2) above, it reduces the data transferred on each visit to 1/4 (size of data / size of HTML). [Note: this analysis is without considering compression; gzip,deflate is very successful in reducing the size of HTML. But isn't prevention better than cure?]
I see atleast the following advantages of this :-
* For most web pages, it will reduce the size of data transferred over the wire.
* Forces web apps to separate data from its presentation.
Disadvantages might include - more complex browsers, time to run the JavaScript program to generate HTML (this might get offset by the reduction in data size).
Now my question is - why are web applications not developed this way, or, why do web applications send HTML over the wire? Surely the web server (sending out HTML) doesn't care about HTML at all, so why should it, first, generate it, and then send it over the wire?
There are a few reasons, some of them historical this is by no means a complete list but just some of my experiences:
HTML predates JS, and a lot of scripts and libraries predate JS
Older browsers (think IE<=6) had rubbish, inconsistent JS engines, their rendering engines were much more consistent in how they treat HTML. So many more libraries and scripts predate consistent JS
It is a nightmare to debug applications written as you suggest if they are not constructed right (we have one at my work, it takes 30 minutes to find where a piece of html is actually generated)
It is a lot more work to do it right - why not use templates or static docs or something much simpler
Its not really a problem - HTML compresses really well
What you suggest is done - its called AJAX (OK, so ajax is more general than this but you all know what i mean)
It simply doesn't work for most plain-text user agents including those used by most search engines. If this page is serving most of your content, its generally a good idea to make it easy for Google to parse
Well the obvious reason on why this is the case is that JavaScript wasn't around when we started sending HTML around, and HTML was an improvement to sending around plaintext documents.
The reason we don't do this now: we eschew complex solutions to problems that aren't really problems.
Average internet connections download nearly 1M bytes per second, and web browsers are quite adept at parsing and starting to render this HTML before it's even all ready to be. They're also great at parallelizing the downloading of resources on the page. If we want to save a few bytes at the cost of some compute cycles, we gzip content before sending it. Problem solved.
And for the record, we do this with AJAX in complex webpages (checkout Github's source browsing for a great example of how awesome this can be).
What you suggest can, and is, done. Remember, web pages used to be static documents. Full blown web-based applications are a relatively recent idea.
I might also suggest that it isn't necessarily more efficient, especially when your pages are sent gzipped.
What you suggest is basically what a JavaScript full stack framework like ExtJS does. You can create rich, data intensive applications without writing any HTML -- well, only enough to reference the necessary .js libraries. The complex DOM needed for layouts, grids, forms etc is all created by the framework.
The simple answer is that HTML is older. Why is C99 not fully implemented with a lot of compilers? They figure 1989 is new enough for them. Also, JavaScript exercises a lot more control over people's browsers than they seem to want. Conditional statements and encoded data pose a security concern, and some people want to keep that can of worms closed to begin with. True, HTML is a very inefficient markup, but the size is insignificant compared to the images you download from the internet. That favicon takes up as much data as the page itself, and it's only 16 pixels across.
A good reason that the server-side code of a web application might do lots of HTML template work on the server side is that in many server environments it's not made easy to bundle up server-side data structures (object graphs) for easy delivery to the client. There may be information kept in server-side data structures that really shouldn't be delivered out to the client. Thus in order to send out a "pure" data-only response, the server would have to trim off sensitive data before delivering out the JSON. That's not an unsolvable problem, but I don't know of many server frameworks that facilitate a solution.
The server has direct, unfettered access to the database and to everything else that makes an application work: user preferences, history, account details, system settings, etc. To build an application that's client-centric for rendering purposes would mean concocting ways of keeping all that information intact and up-to-date on the client. For a lot of applications, that might not be terribly easy.
Finally, it's only relatively recently that it would make sense to trust a browser to provide a stable enough platform for building a long-lived "application environment" as a continually-updating web page. By building a web app such that pages are sometimes completely reloaded, there are lots of little "reboots". That's a cheap and dumb way of keeping a lid on at least some kinds of memory leaks.
Most implementations of sites with heavy Javascript use won't start executing until the DOM has fully loaded; then you'll get every page with 'loading screens' when the page wrapper has downloaded, but none of the content has.
Also, do remember that not all users have Javascript enabled, and not all browsers support high-level Javascript (think mobiles).
I would send HTML in a response if I wanted my application to work without Javascript. I would write HTML rendering code in my server-side language (most of the time not Javascript), which could then be used for two purposes: serving whole HTML pages, and serving bits of HTML in response to XHRs.
If the Javascript code is restricted to things like reporting UI events and replacing innerHTML with server-generated code, I don't have to duplicate any of my application logic across languages/frameworks. This duplication problem is one of the reasons why server-side Javascript is getting people excited.
What is the use of frameworks like PURE or jQote etc. I can do dynamic things in plain javascript or JQuery using AJAX calls or an advanced library like DWR.
What new stuff do these templating frameworks bring to the table? I need to know since I have been asked to use a browser side templating framework without being explained why :(
I guess it depends on what you're using as your server code; it could be that the recommendation came from someone who hasn't heard about N/Velocity for example.
I think the main reason for client templating is that it removes the weight of transformation from the web-server.
It might also allow you to send your JSON from a dedicated box, and serve the template and client code from a different box.
To my mind, both of these 'bonuses' override the fact, that you're putting Data into the DOM that shouldn't be there. Firstly you'll have the JSON that is parsed by the template generator and then you'll have the HTML that is created.
Sure, viewing page source will look neat, but in terms of memory consumption for the browser it's bad, especially if you're in the UK and have Government contracts who mandate IE6 support.
I'm at a stage in which I did not learn internet scripting languages yet, but I do understand JavaScript enough to edit scripts I find on the web to suit my needs. Lately, I've been searching for an RSS to HTML converter, and was surprised to find out that it usually involves PHP. I don't see a reason for JavaScript to not be adequate for the task, so my question is- is it really not? And if so, why?
Also if you can show me some code examples I'll greatly appreciate it (I do plan to learn Javascript eventually, I'm not just leeching. I just lack the time at the moment).
I think the reason most examples use server side scripting is that, since the Javascript same domain policy means you have to request the RSS from your own server anyway, then you may as well transform it into 'display format' on the server side too. Also, if you're doing some sort of Ajaxy stuff then there are better ways of getting the data to the script in the browser than just handing off a full RSS feed.
Having said all that, there are ways to parse RSS and similar XML feeds on the client side. One option is to just style the RSS directly using CSS and/or XSLT. I don't think using CSS for this is too common in the real world because you have to use different methods in different browsers, but transforming XML with XSLT in Firefox is fairly straightforward and I'm fairly sure it's possible in IE and the other browsers too, but XSLT may be a bit beyond your comfort zone.
A good source for Javascript examples is the Google Data APIs as they use the Atom Publishing Protocol which is conceptually similar to RSS. For example, here is the Javascript documentation for the Analytics API.
JQuery has an XML parser built in. Here's a great tutorial that details the use of the built-in feature. :)
http://www.google.com/search?q=rss+parse+javascript
First result appears to be relevant, with source code:
http://www.captain.at/howto-ajax-parse-rss.php