> More painful than about 10 years of manual rewrites? Many apologies, Jon. I did not mean to suggest that you should abandon your question in pursuit of a doomed mega-rewrite. I agree that such a thing would be, er, doomed. I only meant that the "backward channel" solution was sufficiently painful that it was worth exploring other alternatives -- alternatives which might be less work, and which would be architecturally cleaner and would give you a sounder foundation going forward.
However, if you are confident that the "backward channel" is the only way to go, the steps to implement it look something like this: * Sit down with your network infrastructure and IT admin guys to ensure there are no NAT, firewall or client-side anti-intrusion issues to interfere with opening a connection from the Web server back to the client. * In your page, run some JavaScript or create an ActiveX or CLR object that opens a socket and listens on a well-known port. * Implement HandOffToIE so it connects to the client's IP address on the mystery port and sends a message saying "You're in charge, tell me what to do next." * In your JavaScript or ActiveX or CLR object, when you receive this message, do your processing, clear the page using JavaScript ready for the next burst from the server, and send back a reply saying "This is what you do next." * Figure out how to deal with any weird timeout conditions or page misbehaviours from the fact that your ASPX is very long-running and is effectively sending a whole series of HTML pages within a single HTTP response. (I'm not being dismissive here; I genuinely have no idea how a browser will react to this sort of server response.) And stand by to support all the users who ring you up going, "Hey, I clicked Back and it didn't do what I expected!" (Okay, I admit it. Now I *am* being dismissive *grin*.) But, if you'll pardon my frankness, this is a perverse way of writing a Web app. I understand the porting constraints, and I accept that I don't know your legacy codebase, but you're running against the grain of the Web architecture here. You're going to be fighting the natural behaviour of the HTTP protocol, the design expectations of the page generation toolkit, and the built-in assumptions of the browser client. If a HandOffToClient() method is your only option, you're better off implementing a Windows Forms client where you can design a more appropriate bidirectional protocol and a more controlled user interface. > Typically in these lanuages you will create a common header and > footer but create a unique page content for each page. Then the > loop will use the header and footer and simply replace the content within. > I can get that to work fine. What I cannot get to work is to get IE to > return and continue within the loop. The loop is destoryed because > the postback doesn't maintain the state of the loop. Can you think of > a way to maintain the state of the loop after the postback and then return > to within the loop? Two options: 1. Session state. Each page instantiation is one iteration of "the loop." You build the page, stash any state you need to maintain for the next iteration of "the loop" in session state, and exit. The user does stuff on the page and eventually posts back with the next verb. ASP.NET instantiates a new page object and starts running the page code. This pulls the "loop state" out of session state and resumes where it left off. Ryan's message shows how to convert "the loop" to the event-driven model. All you need to add to this is stashing the state before you fall out of Ryan's code, and reloading it before you enter Ryan's code. 2. Client in control. Instead of the server trying to push stuff to the client, let the client pull stuff from the server. Serve up a shell page, and have the shell page run "the loop." So the shell page takes charge of fetching content from the server, retaining (and, if necessary, transmitting) state during the fetch, and of clearing the current page content and fetching new content when required. This is the "client establishes command channel" solution and, as you have noted, one dialect of this currently travels under the AJAX brand name. Honestly, from what you're saying, postback plus session state sounds like a really natural fit for what you're doing. The sequence of HTTP requests from the browser provides the enclosing loop for you; you don't need to run a loop of your own in code. If you can reduce your problem to the example you posted, then Ryan's transformation eliminates code-level looping in favour of postback, and session state should do the rest. > Also the program can communicate with the UI anywhere within code. > So they can have dozens of loops like my sample and have then throughout > the app and even in other subroutines and other called apps If you have a dependency on arbitrary communication between the UI code and the "something else" code, that points towards the "client in control" strategy. Otherwise you do indeed have a lacuna where Page 1 has been served, the user is messing with it, and Page 2 has not yet been requested. "Client in control" means that the IE-side script can call services on the server whenever it fancies. Not that the two are mutually exclusive. You could handle the main page transition cycle using ASPX and postback, then handle subsidiary loops and server callbacks using AJAX-style client scripting. Depends on the nature and complexity of interactions. > the problem is that in a non event-driven language, the code builds > the UI and the UI is not a separate set of code like an ASPX page and > it's code behind That's okay. Nothing mandates separation between the ASPX and the codebehind. If it reduces the pain of porting, you can have a completely blank ASPX and populate it entirely in code. The code that builds the UI *does* have to live on the server, but it's perfectly capable of using client input when it does that building. > In these languages you build the screen programmatically using some screen > definiation syntax. You then place the logic in a loop so the screen will run > until the user hits a key indicating that the program should exit. "Screen definition syntax" = ASPX or codebehind "Screen will run until user hits a key" = dropping out of ASP.NET at the end of serving a page, and re-entering on postback This really sounds like classic Web architecture. You build a page. You hand over control (complete HTTP response). A result comes back (new HTTP request). Based on the result, you build a new page. Lather, rinse, repeat. At the risk of sounding like a broken record, this is exactly what ASP.NET and postback do. Man, I wish we could get in front of a whiteboard and draw a couple of sequence diagrams... this would be so much easier... *grin* Cheers, Ivan -- manaaki whenua | manaaki tangata | haere whakamua http://hestia.typepad.com/flatlander | mailto:[EMAIL PROTECTED] =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
