Re: AJAX...

I don't use HTML in my code unless you count using a
toolkit like eRPG SDK or CGIDEV2.

Because most of my applications before used server side
includes where I would say something like:

<!--#include
virtual="/cgi-bin/loadorders?cust=/%customer%/" -->

I use a LOT of SSI.  "Modular" web programming, almost
piecing each page together with a set of many different
pieces that all fit, each piece being SSI, whether static
or dynamic.

This include was part of my template.  I replaced the
customer variable during runtime.  loadorders CGI program
was called and used another template to format the list of
orders for a sepcific customer.

what I like about this is I'm still using toolkit for
everything, externalizing HTML in templates.  And, when it
executed, I saw the data in the web page.  If I need to
update a page, normally it's just updating one very small
CGI program that returns something like an order list, a
customer name, an order total, etc.  Or if a customer
wanted me to add something like an order total, order list,
etc to another page, it was as simple as adding an SSI
statement to the page they wanted.

This very easily was changed over to use AJAX.  Basically
replacing the SSI statement with a <div container>.  Then,
I could call exactly the same program to build the order
list table without any modification and then return that
via AJAX to the container, displaying the data seamlessly.
 Even throwing in a simple "please wait... loading data..."
screen while it ran.  Very simple.

What I didn't like about this was if I viewed the source, I
couldn't see the HTML returned to the container.  That's
where the debugging issues I had came into play.

Yes, I can call the loadorders CGI program standalone to
see, but sometimes I'm too ansty and want to see things
now.  :)

Make more sense where I'm coming from?  Think of a basic
web page that I create looks something like this (which is
my bvstools.com homepage).

<table cellpadding="0" cellspacing="1" border="0"
width="80%">
  <tr>
    <td>
      <!--#include virtual="/ifshtml/header.html" -->
    </td>
  </tr>
  <tr>
    <td class="border">
      <table cellpadding="3" cellspacing="1" border="0"
width="100%">
        <tr>
          <td width="15%"><!--#include
virtual="/ifshtml/left.html"--></td>
          <td width="65%"><!--#include
virtual="/ifshtml/index.html"--></td>
          <td width="20%"><!--#include
virtual="/ifshtml/whatsnew.html"--></td>
        </tr>
      </table>
    </td>
  </tr>
</table>

<!--#include virtual="/ifshtml/footer.html"-->
</body>
</html>

Now, each one of these include directives may output more
HTML that has MORE SSI statements in them.  For example,
left.html which is the left side bar has an SSI statement
in it that displays a random testimonial.

whatsnew.html, the right hand column, also has another SSI
that displays top 5 downloads which is dynamically built at
runtime.

If I want to redesign my page, it's really just moving
things around in tables since each smaller piece of web
page is separate.

Brad

On Fri, 22 Sep 2006 13:01:40 -0400
 "Bob Cozzi" <cozzi@xxxxxxxxx> wrote:

Brad,
There are a lot of things that are used to make AJAX
"easy". Those things are
not necessarily "easy" themselves. 
But here's the cliff notes version:

Returning XML to the browser:
Use Javascript to parse out the data elements
Update the <DIV> tag IDs with the data.
There is one <DIV> or <SPAN> tag for each data element,
or less than one per
data element. 
You compose the HTML any way you want: Use
FrontPage/DreamWeaver and store the
HTML in the HTML page within its own <DIV
ID="MYTABLERESULTS"></DIV> tags and
hide that set of HTML (that is the <DIV> tags) until you
get the data via an
AJAX call, then show it. Since the HTML is already in the
browser--you don't
have to compose it. For example:
  // Get the XMLHttpResponse
  // parse out the nodes until I have the data element(s)
I need.
  // Update the innerHTML as follows:
  myTabData.innerHTML = myVarWithHTMLAndData;

Then something like this:
 <DIV ID="MYTABLRESULTS">
  <table><tr><div ID="TABDATA"></div></tr></table>
 </div>

If you need it at a table row-level, then insert <DIV>
tags accordingly.

Alternatively, when you populate the <DIV> with the data,
you can include HTML.
This is similar to what you're doing in RPG CGI programs.
So instead of
assigning MyVarWithHTMLAndData to the <DIV>, you do
something like this:
  myDiv.innerHTML = '<td><b>' + theData + '</b></td>';

Similar to what you would do in RPG IV, but anytime you
can externalize the HTML
from RPG IV, it's a good thing.
In addition, if you unload all those myriad string copies
(implicit copies via
the EVAL opcode in RPG IV) from the CGI program to the
Browser, you do get a
snappier response. Doing all the work on the host is okay
and works in situation
where you need that kind of control. But for wrapping
something in pre-formatted
HTML tags, I prefer to do it in the browser.


-Bob Cozzi
www.iSeriesTV.com
Ask your Manager to watch iSeriesTV.com


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx
[mailto:web400-bounces@xxxxxxxxxxxx] On Behalf
Of Brad Stone
Sent: Friday, September 22, 2006 12:49 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] AJAX...

On Fri, 22 Sep 2006 10:43:37 -0400
 "Bob Cozzi" <cozzi@xxxxxxxxx> wrote:

So, do you return XML and then convert that to HTML?

Seems like extra work to me.  :)

Nope never.
I insert <div> or <span> tags and just set the

innerHTML

of the tag to the new
data--the HTML is created in FrontPage or whatever

using

WYSIWYG editing, which
is always easier than trying to compose HTML in RPG IV.

-BOB

Ok, now I'm confused.

Let's say you have a webpage using AJAX.  There is a
button
that you click that says "display order history".

When it's clicked, an AJAX CGI app is run and fills the
div
or span with the order history list.

The data returned from the CGI app is HTML or XML?
 Because
it's created dynamically, FrontPage really wouldn't play
a
part.  IF it's XML, it would have to be converted to
HTML.
 

I don't think we are on the same page.  :)  But maybe... 
-- 
This is the Web Enabling the AS400 / iSeries (WEB400)
mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/web400.


-- 
This is the Web Enabling the AS400 / iSeries (WEB400)
mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at http://archive.midrange.com/web400.

Bradley V. Stone
BVS.Tools
www.bvstools.com