tracker issue : CF-3037100

Problem:

Dynamically Load AJAX Javascript

Remove the requirement for using cfajaximport for tags dynamically loaded in CFDIV,CFPOD and other ajax containers by allowing AJAX UI tags to dynamically load their own dependences. This has the advantages of 
- Dramatically improving AJAX performance and user experience by reducing page load footprints
- Decoupling client pages from ajax service pages
- Removing a developer pain point (remembering to use cfajaximport) 

The proposed change is simple and 100% backwards compatible.

This idea is discussed in great detail in this thread:
https://prerelease.adobe.com/project/forum/thread.html?cap=87529BDA13744B3DB718E841890B9240&forid={81302E9C-2163-4C37-9582-D9C14B236AE8}&topid={D5E7BDC8-EA25-4B68-BFD7-515F9D3BA280}

One of the most detailed posts (sans introduction) is below:
--------------------
     Raymond Camden said:
    Your arguments are making a bit more sense, but I still don’t get one
    thing. CF doesn’t know that I’m going to load something with cfpod in
    it, for example, but -I- know.



Hi Ray,

Sometimes you do not know what you are going to load in your CFDIV, CFPOD or other ajax container because it is governed by what your user does. Other times you do not want to know because doing so would overly couple your calling page to the ajax service.

Consider 2 use cases off the top of my head:

1. A Tab panel that has on the last tab a CFMAP.

The user may or may not choose to view the map.  Maybe only 30% of users choose to view the map. Right now every user’s request must get all of the required JS for the CFMAP, even if we choose to only dynamically load the map itself if a user activates the tab. Yes we can dynamically decide to display or hide the CFMAP, but we pay for it in initial page load time and bandwidth regardless of whether we use it or not.

2. A intranet home page with a staff directory widget in a CFDIV that requires an Auto-Suggest box

In this instance the staff information application is a completely separate application that we do not want to couple with the home page itself. The homepage just knows that it needs to dyanmically mash the HTML from a specific URL into that part of the page. As it stands now, the homepage needs to know that the staff directory widget needs a  cfinput-autosuggest box - even when it is none of the callers business, and might change from one day to the next.

Let me spell out the performance / user experience implications of not pre-loading JS libraries before they might be required a little bit more clearly with another example.

he way things stand all JS must be loaded with the calling page. This can add up to respectable amounts for a page with quite a few different Ajax controls. Having said that, all subsequent AJAX calls from that page load very small amounts, just HTML including script to access the already loaded JS libraries. So a pattern of traffic, including initial page load and subsequent AJAX network calls in Kb might look like: 1000/ 32/ 58/ 24.

Assuming some of those AJAX features were not immediately required on the calling page, and were exposed with CFDIVs or CFPODS or other containers, the usage of bandwidth, and therefore user experience, need not be so uneven. With additional JS loading with subsequent AJAX network calls, the pattern of loading might look more like 500 / 400 / 100/ 245. Now initial page load requires half the usage of bandwidth (that is instead used later). But if the user only triggers the first AJAX call, the bandwidth from the 2nd and 3rd call is completely saved. And CF AJAX page appears twice as lightweight for the same user functionality.

Now a sophisticated application might choose to pre-load all JS - and they would continued to be able to do so using cfajaximport - but the point is that now the developer can make a choice. And they do so by simplifying there existing code.

So to recap, there are 3 reasons remove the requirement for cfajaximport for dynamically loaded ajax tags:

1. Decrease in bandwidth usage (no bandwidth ’wasted’) and decrease in initial page load bandwidth (ie JIT JS loading)
2. Removal of coding requirement for cfajaximport when it is only to cover tags that might appear in ajax containers.
3. Removal of coupling between calling page (with ajax container) and page providing ajax service.

How is this achieved?

1. a New JS function for dynamically loading JS/CSS libraries where they are not already loaded. It might be called like this:


<script>
requireJsForTag("cfinput-autosuggest");
</script>


2. this small function is loaded with any ajax tag or function

3. Behind the scenes, CFAJAXIMPORT is changed to call this function

4. All other CF AJAX tags now insert markup that begins with the requireJsForTagFunction() to ensure their dependences are loaded.

Notice that this implementation is 100% backwards compatible.

Thats it. I hope I have not overly balabored the point but if I do it is only so I can convince others how simple the change is (relative to the gain) and how many upsides it would have. And the best thing about it is that to take advantage of it developers only need to stop using cfajaximport in some places!

Let me know if I am missing any considerations. I will file an ER.

Ben Davies 

Method:


Result:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3037100

External Customer Info:
External Company:  
External Customer Name: Ben Davies
External Customer Email: 447227C844C7765A992015A8
External Test Config: 12/18/2008

Attachments:

Comments: