Got a large initial aspx page with some graphics (several, throughout the page). Using VS2005 + AJAX (started with VS2008 Beta 2 and FW3.5) and VB (preferred, could understand C# too).

My concern  is that the page is slow to load at slower connection speeds (modem connections). It is important to me to give a rounded-up message before asking the reader/user to click for the next page, so I do not want to split this bigger page into several smaller ones. Screen scrolling is generally acceptable.

My idea is to organize the page into several <div> and send them to the client independently as they are ready, and display them there as they come (?). That way the user would have something to read, while other parts of the page would keep coming (and she/he would later scroll down to see them).

I believe this is a fairly reasonable request, yet I was not able to find anything specific on how to do that.

Would someone at this knowledgeable Forum have a solution/suggestion where to start and how to go about it? I might be completely on a wrong track. There could be some other, quite regular way... while I am banging my head against this wall...

P.S. Learning about AJAX, I went through a number of  these excellent "How to"-videos. The one about the "Incremental Page Display Pattern" (video No.28) seemed just right, until... There Joe S. creates a Web service that waits for the part of the page to get ready, but then he does not display that part, but sends  a "Hello World" text message instead. I followed that example and displayed my textual messages in IE7-client as the <div> got ready, but I do not actually know how to display my <div> instead. This may all look very easy to you, and it seems there must be a way, but I do not know it. If the Web service is alerted that a particular <div> is ready, there should be a way to grab that ready part and transmit it. I don't really see much of a point in waiting for a <div> to be ready, and than sending a completely different message, even if that was the exact HTML of that <div>. Would anyone have a suggestion where I could read/research this subject further (any particular text, link...?)

Thank you heaps.

hello.

well, you could do that with ajax, but i'm almost positive that what you want to do is, from the server side, to send "portions" of the page back to the client. that is normally done by calling the Response.Flush method, but normally you don't use it because you leave the rendering of the page as is.

now, if you want to do this with AJAX, then you can just generate the divs on the server side and then, on the client, you'd call several web services that return the data show in thoses divs. Do notice that this means that you'd have to write js code on the client to generate the HTML that would be inserted on those divs...

The simpliest way I can think of is to have a bunch of update panels on the page where you want to load different things.

Then use one of the ajax timer examples to refresh the page (or only a particular panel if you want), on the next postback, fill another div.  Repeat until all divs are filled.

Not the best solution, but by far the easiest to implement I believe.

You might also be able to use the dynamic popluate control from the control toolkit, although, if there are form elements in the divs, that won't be very good as it will be hard to hook up events to the controls.

Thank you, Luis Abreu, for your suggestions. Could you please be more specific with the Response.Flush approach? I investigated that, but could not see how to break a large page into several pieces and Response.Flush them to the client, to display them there as the original large page.

I do not particularly want to use AJAX. I just need a solution, any whichever good way.

Your second suggestion is in line with the Joe S. video example. If I understand it correctly, I would initially send the modified "large page" to the client, where div-s would be just blank spaces. Then, using a Web service, the client display could be populated asynchronously, sending each div HTML as a string. A bit tricky, it may work, but any change/maintenance of the div display (HTML, line by line, not to mention the CSS effects) would be rather awkward, a potential nightmare. I will work on this concept to see better what can be done, yet it is far from elegant or effective.

I am actually surprised that this rather ordinary request, sending the original large page (not a postback) efficiently) has not been addressed before. The problem must be rather frequent...

Joe S. mentions the pageflakes.com Web site. It seems they are using this blank-div-spacers approach, and one can see how their home page is populated as the content becomes available.There is even an example related to that. Will have to investigate this further, with the focus on how to put the div content together.

Best regards. Alan

Thank you for your suggestions, Motley.

If I am not wrong, a bunch of update panes in combination with a timer may not exactly make the display of the page more efficient, and that is the basic request.

As per the AJAX dynamic populate example, that either requires a User input, or it should be triggered by a timer (which is actually the first approach above). Please do not forget it is the initial page, so the User has not seen anything yet. She/he has only typed in the Web address, or used a link to the site. The idea now is to display a fairly large page as fast as possible. Instead of buffering the whole lot at the server and sending it across when it is all ready, the ideal solution would just send the initial, rather simple textual portion to the client, for our User to have something to read, while the rest would be quietly appended to the displayed portion as it becomes ready.

It seems the automated asynchronous approach, like with the Joe S. video example (Incremental Page Display Pattern, No.28) would be the best one. No extra timers that could only introduce extra delays. Let the page parts pop up at the client as they become ready. My problem is how to send the page parts.

If the Web service is alerted that a <div> portion is ready, say DIV1, would it not be normal that the Web service is aware where DIV1 is, could grab it and send it to the client as an object, not caring about the actual content of it and how it is HTML-formatted?

hello.

well, the problem of my suggestion is that you'll have to intercept the render event. probably the easiest way of doing it is to create your own form derived class and then override the render method. you'll have to copy the base's class method and then, instead of delegating to the base class, you should go over the form's control collection and call render followed by response.flush (do notice that i haven't tested any of this and i'm just putting here some thoughs. maybe they won't work)

Thank you, Luis. I appreciate your advice and good will.

There should be an easier way then to rewrite the page rendering process. Such an ordinary request, to be able to send a larger page in pieces... It seems I have opened a can of worms...

hello again.

well, you won't have to re-invent the wheel. you just need to go through all the elements on the collection and call their render method followed by the flush call.

Yes, Luis, I appreciate what you are saying. Yet I am reluctant to mess in such basic functions as page rendering methods. If I invest the work and even make it work, and tomorrow Microsoft modifies something about the page rendering, bringing in some new features that are good to have, or even disabling my solution, I have created myself a problem. I would have the pain of maintaining that modification forever.

As much as your idea should actually work, it would require considerable work and may create future maintenance demands. It seems wise to stay within the frame of the standard system supported functions.

Thank you anyhow. A good exercise of thoughts.

I feel I should share my recent experiences on this rather common challenge, for the sake of others who inevitably will face the same problems. I am actually rather surprised that some of more experienced gurus of this forum did not react - probably they have not seen the posts ( ?).

Well, my initial problem originated, as usual, from my own ignorance.

Searching for the most effective way to display a complex Web page, something that may go into tens of seconds over a slow dial-up connection, in increments so that the users gets first parts relatively fast and they get something to do while the rest of the page is loaded, I implemented the incremental Page Display from the AJAX samples (#28, by Joe S.). As my test revealed, that simple textual part, the beginning of my page, which I sent in through the Web service (as the exampole goes) came in actually slower than the rest of the page. It came distinctly at a different time (I have a fast cable connection and a very fast development PC, but the difference in time was still obvious), but after the rest of the page was loaded. It was an eye-opening experience.

1) If I was to use that Incremental Page Display example, I should use the Web Service approach to send in the slowest parts, the complex graphics and similar.

2) The second conclusion is for me far more interesting. It has nothing to do with the Web Service approach. I actually noticed that parts of the complex page have come up on the client (IE7 browser) screen at distinct times, and not in the physical sequence as the page is written, but as they obviously became ready. That was exactly what I needed!

My initial page design (just laugh, it is OK! I am learning...) used tables, actually one large table, to position the elements on the page as required. I have seen that from many examples, and even now on the Web there are many, many cases like that, probably the majority. Obviously, the page did not display until the table was formated by the browser. So, it was sloooow...

Then I discovered that some authors are recommending DIVs. Initially it seemed more complex, and I did not have the logic that would explain why... Until my test.

Also, the documentation describes the server side page preparation by IIS as buffered by default, meaning it prepares the complete page before it sends it out. I contemplated experimenting with declaring selected pages as un-buffered, but did not get that far to actually try that interesting idea (maybe someone wishes to comment?)...

But what I had done in re-writing my page was to restructure it into DIVs. And now I saw it at the client screen that these DIVs are displayed as they get formated by the browser, popping all over the screen in the inverse order of their complexity.

That means that I can display any page in parts by just organising it into DIVs.

And that is all I need. Perfect.

To me, it is an important experience.

I would love to read somewhere in the documentation anything explicit on this DIV and page rendering process. If anyone reading these lines would have a link, or a suggestion where to start with this type of research, I'd be grateful.

So, I just thought someone else might benefit from reading about this experience...

Cheers...