Generating an iFrame within a table? 1

[jsteph]

Hi all,
I have a table, and in one of the cells of each row I want an iFrame. This table is generated via asp code on the server, and the iframe's contents will be another table--like a sub-table I guess.

So then on certain events via javascript I'll reset the src of the iframe, changing the contents--the src will begin it's life blank, because I want to pre-generate the iframe's table contents.

So the problem is, on the original generation, I don't have an actual 'file' to set in the src tag--but I do have the actual html table code. I've tried just generating the html between the <iframe> and </iframe> tags, but that doesn't seem to work.

Is there a correct way to 'pre-generate' an iFrame's contents, or must i always use the src tag? BTW, on a lark I tried to put the html table in the Src tag and that didn't work either,
Thanks,
--Jim

 

[ChrisHunt]

Multiple iframes within a table? Sounds utterly horrible. Still, it should be possible - just generate your iframes like this:

<iframe src=""></iframe>

Or, if that doesn't work for you, make a dummy page that's just blank and start with your iframes pointing to it:

<iframe src="dummy.htm"></iframe>

Then you can redirect the src as and when you see fit.

However, what are you hoping to achieve with all this? I can't help feeling that this isn't the best solution.

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[jsteph]

Chris,
Thanks, I ended up just not pre-generatig the html and am doing it in the OnLoad event of the page body.

Essentially what I'm after is a Master/Detail data set. Each row in the html table (Which is in it's own iFrame) has detail records, which I store in a table in an iframe in a cell at the end of the table. Clicking on this iFrame in the cell expands it so the user can enter data, which is updated behind the scenes using ajax methods.

I got it working, and it seems fairly robust, but if there is a better way, I am definitely interested.

It's just that all the methods of dealing with Master/Detail data so far involve at least four painstaking pages--a page for the rows of master data, then click one line-item (record) and get a page with each individual field for edit, then click on a button to bring up detail for that record, then once again select a detail line-item and bring up yet another page to edit individual detail fields.

I'm now able to edit/update any field--master or detail, smoothly without any page reload.
--Jim

 

[Vragabond]

jsteph,

If you still want to pre-generate the html, you could load about:blank in the src. It's a valid way of loading an empty page in the browser.

___________________________________________________________
[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]

 

[Olaf Doschke]

I wonder why to use iframes, you coul put the html directly into a table cell (td), and overwrite the innerhtml of such td tags. No need for frames, no need for complete html files.

Bye, Olaf.

 

[jsteph]

Olaf,
My original thought for iFrames was that when I want to refresh one of the iFrame's contents with the latest database info, I just use javascript to set the Src tag to an asp page that hits the table and generates the html.

I suppose I could do it with a call to xmlhttpRequest to fetch the data and plug it into the cells, but that's a lot of javascript. Plus, inside each iframe is an html table with <td>'s and within each td is an <input> because this is a fully updateable html table. I've had issues trying to get html <td> contents to be updateable without an <input> element.

I know it's a heavy bit of html on the final page, but in practice this app will always be filtered data--ie, the 'main' page will typically have <40 rows, and within each row the 'sub-iframe' in that row's cell will have about 5 detail rows.

It loads in about 3 or 4 seconds, which is borderline unacceptable for me--but this is only because I can't yet pre-generate the sub-iframe's html content. What I'm left with instead is using the OnLoad event and there i'm looping through the main tables <tr>'s and setting the Src property for each row's sub-iframe. This is of course a call to the server for each of the 40 or so rows.

So that fact is the impetus for my original question--if I could omit that OnLoad call which makes roughly 40 server calls for Src changes I could speed up the original load substantially. Then of course each edit the user does I can choose whether to just not refresh the iframe and check the record's timestamp on any subsequent update to make sure the displayed data is still fresh--or just refresh the iframe which is quick and doesn't cause the main page to reload.

So bottom line--I've tried the blank Src and embedding the <table>....etc. html in between the iFrame tags when the mainpage load, but that just doesn't work for some reason--i have to explicitly set the Src in order to show the data.
--Jim

 

[Olaf Doschke]

I wonder if that would be so much javascrip, the request, getting the td element with getElementByID for example and setting it's innerhtml. Your script wouldn't need to create a full html page, just the html form needed in the table cell. And that would reuse what's already been loaded, eg CSS etc. It's one of the general ideas of Ajax to replace the need for frames.

Bye, Olaf.

 

[jsteph]

Olaf,
That does sound promising, and I will definitely start moving in that direction. Trouble is that for now, I've got a deadline so I'm getting this out the door with the iframes, but version 2.0 will hopefully do things using the DOM model in javascript. I actually do some of the gruntwork in this app that way now, I'm just not ready to do the meat of it there.
Thanks,
--Jim

 

[Vragabond]

And src="about:blank" did not work? Which browser did it not work in?

___________________________________________________________
[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]

 

[jsteph]

vragabond,
I have not tried that yet. I've tried the src="" and the dummy. I'll try that later today and let you know,
Thanks,
--Jim

 

[jsteph]

vragabond,
I tried src="about:blank" in IE 7, and it doesn't work.

I do a viewsource on the 'parent' iframe, I look in the 'child' iframe, and the src="about:blank" is there, and the entire html table is between the <iframe> </iframe> tags.

Is it possible that I'm putting the html in the wrong spot within the iframe?

Thanks,
--Jim

 

[ChrisHunt]

Is it possible that I'm putting the html in the wrong spot within the iframe?

Eminently possible - you shouldn't put anything between the <iframe> tags, you put your stuff at whatever address the src attribute points to. But then the whole process sounds a bit confused:

It loads in about 3 or 4 seconds, which is borderline unacceptable for me--but this is only because I can't yet pre-generate the sub-iframe's html content. What I'm left with instead is using the OnLoad event and there i'm looping through the main tables <tr>'s and setting the Src property for each row's sub-iframe. This is of course a call to the server for each of the 40 or so rows.

1) I'm not sure you'll gain anything by pregenerating the iframed pages. If it takes time to generate each page, that time will be consumed as the user requests the main page - whether the generation of the sub pages happens before the main page is painted or after, the appearance will be the same. But then that assumes that I understand properly what you mean by "pregenerating" the iframe content, which I probably don't, but then I'm not sure you do either

2) Firing a bit of javascript for each row won't in itself cause multiple extra calls to the server - it runs client-side. Whatwill cause 40 server calls is having 40 iframes with 40 different src attributes. That's a recipe for performance disaster.

So here's an alternative approach:

Build your main table with no iframes at all. Then, when the user clicks the "edit" link, create a single iframe with javascript on the fly to do your editing in.

Or, ahem, pregenerate a single hidden iframe when the page is first displayed, and move it and populate it how you need it when the edit link is clicked.

Actually, before I did any of that, I'd look around for stuff on the web that's already written to do this job. You're not the first person in the world to want to update a multi-row table in one visit, why re-invent the wheel?

-- Chris Hunt
Webmaster & Tragedian
Extra Connections Ltd

 

[jsteph]

Chris,
Thanks, I did look on the web. I found Ironspeed, and it seemed to have promise though was not acceptable because it didn't do the multi-row thing--it required a click on each row to bring up a separate edit screen.

The hidden or none at all iframe ideas are excellent thoughts but the specs for this project require the user see at least the first few detail records of each Parent record. The specs are that they want to quickly scroll through a set and see each line and some of the detail for each line--knowing if there's a lot of detail they have to scroll--but having to click each Parent row to bring up any detail at all was specifically stated as a deal-breaker.


So the whole 'pregenerate' idea was that I figured while the main iframe, the one with the Parent records, is being generated--since that's on the server--why not load all the detail records embedded into the html of the main table as well while we're there at the server? This is my dilemna--that doesn't seem possible (with iframes anyway).

So in lieu of pre-generating, I do indeed make the 40 or so calls to the server in a function called in the onload event. Each Parent row's 'sub-iframe' has it's src set in this function to an asp page, which recieves the Parent's key as one of the querystring variables, and that asp page builds the html for the "sub-iframe" and its table. So that's what I wanted to pre-generate.

On the bright side, I'm actually pretty close now, it works very smooth--with only the initial load being slowish. But that 40 record main page was somewhat of a worst-case scenario that I use when performance testing--most users will have between 5 and 15 records and that loads quick.

I think eventually I'll probably drop the sub-iframe approach, and just generate a sub-table. My whole reason for the iFrame was simply that I'm more comfortable writing asp code than javascript--if I have to make a server call anyway to refresh data in one of those subtables, I felt more comfortable making a simple src=blah.asp rather than the xmlhttprequest call then parsing that data in javascript.
--Jim

 

[Olaf Doschke]

Well, an xmlhttprequest isn't bound to return XML, you can call your asp page and receive the html it returns. NO processing needed. In fact you can shorten that asp script to generate html header and body and let it only create the subtable.

Alos tables are rather slowly rendered, you could do the same with Divs or even lists and approriate CSS.

Bye, Olaf.

 

[Vragabond]

Jim, I must admit, I don't really understand most of your logic or even what you're trying to achieve. I just think you're trying to reproduce native iframe behaviour via javascript. I didn't understand how you tried my suggestion, but you should've done it like so:

<iframe src="about:blank"></iframe>

Repeat this for all iframes on the page, but add name, id and other attributes you need. This is the necessary code to output an iframe that loads a blank page.

___________________________________________________________
[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]

 

[jsteph]

vragabond,
That's the exact syntax I used--but I'm not trying to generate a blank iframe--I want an iframe that already has it's innerHTML generated and loaded on the server. In other words--I understand an iFrame's behaviour to be that it takes a src parameter, and fetches that page from the server. I still want that ability to fetch a *new* set of data from the server without reloading the whole page--BUT--the key point here--the *initial* contents of the iframe I would like pre-generated at the server since the rest of that initial page is being generated on the server.

That's what's not happening--and maybe that's by design--when I do a view-source of the parent iframe that is correctly showing the sub-iframe data--the view-source text does not show innerHTML of the iframe--even though the data is there. So I was probably going down the wrong road thinking I could fake it to make the iFrame's innerHTML on the server and expect it to display.



What Olaf is saying is right--maybe I'm mistaken in using an iFrame to begin with. But my choice is due to my lack of experience with CSS. I'm comfortable working in ASP, generating html, but the mental block I have is returning html to a javascript function and dealing with it. I'll look at educationg myself and moving towards those methods in a future release of this app.

The good news is that it works very well now--as is--with the iFrames. Users can add and update detail records without a blink--just like the old MS Access Form/Subform model used to...and that's what my goal was. Like I said--the typical user will log in and he has around a dozen locations which he oversees, and for each location he updates parent-level information, as well as adding/updating detail level information. For situations where the business reality will require a user to load hundreds of records at once, I may change the model because even in MS Access, I rarely would show hundreds of records with visible subforms at the same time.
--Jim

 

[Olaf Doschke]

a simple example of writing to the dom with javascript. Prerequisite is, the td cells with no inner anything (no iFrame) have the class="detailrecordcell" and in their ID attribute the ID of the detail record you would need for the url of the asp page to retreive that record (untested code, may need cross browser support added):

var req = new XMLHttpRequest();
var cells = getElementsByClass("detailrecordcell");

for(i=0; i<cells.length; i++)
{
 /* you know the name of your asp better than me */
 var url = 'getrecord.asp?id='+cells[i].id;
 req.open("GET", url, false);
 req.send()
 cells[i].innerhtml = req.responseText;
}

 

[Olaf Doschke]

later on you could change the script to send back all records, then split the Responsetext for each cell with javascript and fill the cells. Then you have only one initial request. Later on you could refresh single cells based upon their ID.

Bye, Olaf.

 

[jsteph]

Olaf,
Thanks, that is something very much like what I'm looking for--it appears to do what I'm doing without the iFrame. I'm going to make a test page and see how that works,
--Jim

 

[jsteph]

Olaf,
I'm trying to make that work, and the getElementsByClass is not showing up in the intellisense dropdown in MS Visual Interdev. I'm developing for IE7, and I get the error "Object Required" at the line with getElementsByClass.

Do I need a meta-tag or something, or does ie7 not support that method?

I have the <style> hardcoded in the html, I'm not yet using a style sheet, I'm wondering if that has an effect?
Thanks,
--Jim