> From: Pops
> I think, and this is more of a question, I think I need to 
> first create a new WCX that creates XML or JSON output only 
> to begin to take advantage of JQUERY.  Then second, I need to 
> "bind" if that is the proper JQUERY term, the JSON fields 
> with a Table columns.
> 
>     - Create a WCX "web service" that returns JSON (or XML) output
>     - Bind the JSON fields with the Display fields.
> 
> Does that sound correct?
> 
> If I can see a quick example of how JQUERY will be 
> conrstructed, in particular having it do:
> 
>        - Periodic Ajax Calls
>        - Bind the JSON result to table elements
> 
> then that will go a long way to completing this examination.

I wasn't paying close enough attention - that's the overview I was looking
for in my other message. :-)

Here is a key question: Will the customers of your web service be calling it
from JavaScript on websites loaded from their own domains? If so, then you
won't be using AJAX at all. In jQuery code, that means you won't be using
$.load(), $.post(), $.get(), $.ajax(), or related methods.

It's possible to make cross-domain AJAX work if your customer runs a proxy
on their server, but not if you want a pure client-side solution.

Instead, you have to provide your data as executable JavaScript code, which
the browser can load using a dynamic script tag. That's what the JSONP, or
JSON with a callback, format does - it wraps up JSON data inside a callback
function that will be automatically executed when the data is loaded.

You can still use either the innerHTML or DOM creation techniques that Dan
mentioned in his very helpful reply, it's just that you won't be using AJAX
to download the data.

Here's another key question: What do your customers want to do with the
data? Do they just want to insert some prebuilt HTML to the page, or would
they want to get at the individual pieces of information in your data from
JavaScript code?

In other words, going back to your template example:

> <table>
> <th>Node #</th><th>User Name</th><th>Time Online</th> 
> @LOOP.NODES@ <tr>
>    <td>@NODE@</td>
>    <td>@NODE.USER.NAME@</td>
>    <td>@NODE.TIME.ONLINE@</td>
> </tr>
> @ENDLOOP@
> </table>

You could download this as HTML, e.g. with two nodes:

   <table>
      <th>Node #</th><th>User Name</th><th>Time Online</th> 
      <tr>
         <td>123</td>
         <td>Mike</td>
         <td>1:00</td>
      </tr>
      <tr>
         <td>456</td>
         <td>Pops</td>
         <td>2:30</td>
      </tr>
   </table>

Or you could use JSON format for the data:

   {
      "nodes": [
         {
            "node": 123,
            "user": "Mike",
            "time": "1:00"
         },
         {
            "node": 456,
            "user": "Pops",
            "time": "2:30"
         }
      ]
   }

The HTML format obviously makes it trivial to insert this into your
document, but it's hard to access the individual data items in JavaScript.
The JSON format makes it easy to access the data directly in JavaScript,
e.g. nodes[0].user is the username in the first row.

And one last key question for now... Is the expectation that your customers
will be loading into their pages some JavaScript code that you provide for
them (whichever of these downloading and data formatting approaches you
use)? If that's the case, you probably shouldn't be using jQuery - or any
JavaScript library - at all. Instead, you should package up a completely
self-contained solution that won't interfere with other scripts the customer
may have on their page. But before we discuss that further, let me know the
answers to the Three Key Questions in this message. :-)

-Mike

Reply via email to