Shoutbox problems

[GettinBetter]

Hiya people,
Have read a few posts about simple shoutboxes (and how easy they are ) but I'm having trouble.
I have made a form using iframes, and the messages are shown in the top iframe, with the name and message being posted from the lower iframe.

I have three files a config.php (read once), shoutbox.php, and post.html

The shoutbox.php uses the the config.php to access the DB, and send the messages to the main window, and the post.html produces the text entry forms in the lower frame.

It was working fine when it was all in one iframe, but not now that I've modified it.

I think its not posting the variables from the post.html to shoutbox.php

Would appreciate any suggestions.

[john tindell]

Do you have any code? What modifications did you make?

[GettinBetter]

I modified it to make the input section appear in a separate iframe, (i.e previously the page that appears was all echo'd at once to that single iframe).


The site that I'm using to test it is here
and the code is available here

[penagate]

Urgh! Frames!

If you dislike having to reload the whole page just to update the shoutbox (and who doesn't), you should use an XMLHttpRequest object to post the shout message and receive back the shoutbox contents in XML form from your server-side script. Read up on "AJAX" for more information and tutorials of this technique.

If you want to expand on that, you could use a pseudo persistent connection so that the shoutbox updates itself whenever a new message is posted. But get the posting working without frames first. You'll find frame-less development far less of a headache.

[GettinBetter]

OK, thanks. I'll have a read up on that subject.

If you want to expand on that, you could use a pseudo persistent connection so that the shoutbox updates itself whenever a new message is posted.

Yes, thats exactly what I want eventually. I have seen an example where the page is refreshed after the certain time has expired, but it's rather annoying seeing the progress bar (in the status bar) keep loading, some people would also have to listen to some sort of audible notice as well. Perhaps its possible to look at the last id in the DB, and if it's changed, then refresh.

But get the posting working without frames first.

I've done that, and have moved onto try and get it the way I would like it.

You'll find frame-less development far less of a headache.

Yes I realise this, but thats not what I really want. I personally think it looks nicer in two separate iframes.

Urgh! Frames!

I don't quite understand this response, could you elaborate?

[penagate]

Frames are an ugly, outdated technology, and just plain unnecessary in today's web.

Examine the principle of a well constructed web page - relevant, meaningful markup that constitutes a well formed document structure, containing the (usually textual) content. Ignore anything else, like styling, or scripting, for now. This is a web page doing what it was intended to do - nothing more.

Now introduce the concept of a frameset. Multiple documents each with their own viewports, displayed together in one master viewport, with navigation taking place within the individual viewports. This already introduces ambiguity - where is the user? What page are they looking at after several internal frameset navigations? Most browsers will only show the frameset URL in the address bar, and not update when they navigate internally - making it difficult and unintuitive to bookmark the page or send the link to someone. Plus, it also introduces the issue of security - what if the frameset attempts to use scripting to manipulate a page displayed from another website?* The once innocent, simple premise of displaying a web document turns into a complex page management headache, because the model has been polluted by introducing the clutter of frames.

But you probably knew all that, and you can read more here: Why Frames Are Bad.

Inline frames (IFrames) are slightly less evil. They do have their uses - they can be a convenient, quick way to show a completely different page within its own little viewport in the document. But, like any element, it should used meaningfully and in a situation where it makes sense in the context of the document structure. And you should never try to blur the line between the document that it is situated in, and the document it is showing - meaning that one should never use an IFrame to show a part of the main document. Which is exactly what you are doing with your IFrame model shoutbox. None of your shoutbox actually exists in the document. It may appear that way to the visitor with an IFrame capable graphical web browser, but not to anyone else - the document on its own does not make sense, and that means it fails its primary goal as a web page.

Now, pseudo persistent connections. Actual persistent connections are not possible over HTTP, due to its inherent response-request model. But, you can quite easily fake one, using a background connection to a server-side script that loops until it has a message to flush downstream to the client. A problem with this is that you need to be aware of timeouts - the script will most likely have a maximum execution time imposed (30 seconds default in PHP) and the browser may also have its own HTTP request timeout period. So you will have to compromise slightly by flushing a response every 25 seconds or so even if there is no actual message to send. This requires some co-operation on the part of your Javascript code in order to re-establish the "connection" request appropriately.

Using this model, you avoid the problems with refreshing the page and possibly interrupting the user in the process (for example, auto refreshing news articles are extremely annoying). You will also have an intact, meaningful, and in-one-piece document structure, both initially and as it is dynamically updated.


* Browsers already address this.

[GettinBetter]

Wow, that's a fantastic reply, and no, I didn't already know that. I had a look through the link you supplied. I have at this time no real response to your post except to say thank you for your comments, which I will take on board. I will go away and try and approach this from another angle.

All the best.