If it's a w3 extension and not a browser-proprietary hack then sure. Though I would love to avoid javascript, etc. so I can use the web interface over links or w3m, but that's probably not going to happen.
innerHTML isn't a w3c property IIRC, but it's supported by IE, Mozilla, Opera, and I'm fairly sure recent khtml. At any rate, innerHTML is a convenience and not really a necessity.
Doesn't this mean the same amount of data will be flying around? The array
will be essentially the same size as the popups... which is part of
the concern, also obviously very large html files which this will
solve.
Actually, with this approach, the array is going to be probably about 30-40% the size of the existing guide page, because there's quite a bit of html overhead in those popups. On my Expressvu with about 140 channels, assuming an average of 3 programs per row, it would be roughly 60k of data per display. That's a fair bit when you're connecting over dialup, I admit, but mod_gzip would crunch that to 10k. (I'm not sure if mod_gzip or something similar is available when using Python as a webserver.)
Still, your concern is perfectly valid. If the goal is to minimize the data transmitted as much as possible, this approach isn't the right way to go.
So I've worked up another approach which moves most of the logic back to the server. To handle the popup, I use a hidden iframe, and when a grid cell is clicked, the iframe's src is set to hit the server, passing it the program id. The server then sets the appropriate data using Javascript in the parent frame to update the popup.
To see this in action, go to:
http://people.auc.ca/tack/guide/
View the server-side code (prototyped in PHP) here:
http://people.auc.ca/tack/guide/index.php.txt http://people.auc.ca/tack/guide/popup.php.txt http://people.auc.ca/tack/guide/progdata.php.txt
(progdata.php isn't something that's ever sent to the client in this approach, but I include the test data here so you can see what the rest of the server side code works with.)
Executing javascript in a hidden frame is a common trick to prevent redrawing on the client. With this approach, I pop up the window immediately and display a "fetching data message," which is then removed (hidden, actually) by the javascript code executing in the iframe. This approach adds a bit of latency to the popup, but it's not bad, and in fact on a local network it probably would be barely noticeable.
I think I prefer this approach more than the last one, actually. The logic is much more straight forward -- doing lots of DOM manipulation in JavaScript is complex and annoying to debug.
On the UI side, I dropped the table and used float divs. The disadvantage of this is that the grid must be fixed width (though an onresize handler can update the grid when the browser is resized if need be). The advantage is that we get much more flexibility over the display, especially for programs whose start times aren't aligned grid times.
Let's just do the whole thing in ActiveX :)
I double dare you. :)
Cheers, Jason.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
