Skip Navigation

I just lost a REEEEAAAALLY long message . . .

Travel Forums System Talk I just lost a REEEEAAAALLY long message . . .

Page

Last Post

11. Posted by Hien (Moderator 3906 posts) 12y

Hi Peter,

Javascript can be considered as a standard feature in browser since years ago. So, you don't really have to worry whether it is supported or not. It kind of acts as a first-layer validation to ensure the entries are correct before they are being sent to the server (and probably validated again). As long as the script is standard (i.e. checking whether the input box has a value) and does not contain browser dependent feature, it will not pose any problem to users.

I noticed that your website expires the pages immediately and does not allow caching. If anything goes wrong after the form has been submitted, clicking the back button doesn't retrieve the previously typed message because the page will be reloaded fresh from the server again (with an empty form).

So, I really think that having a client side validation actually helps the user to confirm that everything is ok before the browser sends the message to the server. It gives the user some sense of security that everything they keyed in is correct. Perhaps you could also add a confirmation box to the form to ask the user whether they are sure to send the message. This will ensure that they did not clicked on the submit button by mistake or accidentally pressed the enter key.

Anyhow, I suggest that you enable page caching for the message compose pages so that users could go back to re-submit the form, if something wrong happens such as line disconnection or even intermittent link down/dns errors.

As for the logging off, I am sure that having a hidden blank page reloading every 5 minutes will help to prevent time-outs. This is because whenever a page request is being sent to the server, the server actually resets the browser session time-out clock and it ticks again from 0 sec. This means to say that the person is kept logging on to the server when he is composing the message. Unless your site is not using the browser session to keep track of the logon status, you should have no problem implementing that hidden page-refresh thingy.

If you need assistance on Javascript and IFRAME, I will be more than happy to lend a helping hand. :)

--
Hien

12. Posted by Sam I Am (Admin 5588 posts) 12y

Hi Hien,

I think you are probably right with regards to the not losing of messages. Something to make sure these aren't lost when hitting some incorrect combination of keys (this is what happens to me all the time with my clumsy fat fingers....) would be a good idea.

Pete, what do you think? Hien, Pete has a (little) pet peve regarding java script.... just some background history there ;)

Cheers,

Sam

13. Posted by Peter (Admin 5789 posts) 12y

Hey guys,

Are people really having a hard time with the message validation as it is now?? I don't really see how any more validation will change things. Apart from the fact that the server side validation is browser proof, adding javascript validation will mean more code and therefore slower loading pages -- and to what avail. If someone can tell me when the validation fails, I would be happy to fix it, but at the moment I can't find a fault with it. By the way, when I hit the back button the stuff I typed into the form is still there- is that just me or does it wipe out other people's forms? Could someone verify that and if it is losing the information, let me know what browser you're on and what the exact situation was?

Caching pages is a bit of a problem considering there is dynamic information on any page that needs to be checked everytime it is loaded (ie.. whether there's any new messages, whether the user is logged in, new posts in the forum, etc.).

As far as the logging on goes, the sessions use the coldfusion session scope, so I don't think a html page reloading would be enough to keep it alive. Thanks for the suggestion though.

Cheers, Peter

14. Posted by Sam I Am (Admin 5588 posts) 12y

I have no real problem with the validation either, the problem is that sometimes in the forum or message center entire messages go lost without being sent. There could be a few reasons but these are what I have noticed.

I hit some combination of keys by accident and it takes me back one page or up one page or something. If I then hit forward/back on my browser, the entire message is gone and it is not sent. That's a frustrating one.

The other one has to do with a time out which when it validates the session and finds out your session has timed out will automatically lose your message. Also no saving it by hitting back.

The last one might be when your message is too long and goes over the character count limit but I am not sure whether that one also removes the text you have typed or just gives an error above it....

Just what i have noticed.

Sam
ps. I just tried it with this post and hit submit and then back (also gone). I am running Explorer on Windows XP...

15. Posted by Peter (Admin 5789 posts) 12y

Hmm.. well there's only so much I can do about people hitting a bunch of random keys
;)

The session problem is duly noted - unfortunately it is a really tricky one to solve and I have racked my brain for hours trying to figure it out -- will do this some more soon I guess :)

The message being too long problem was solved quite some time ago and now it should just give you a message saying how many words your message was over limit.

The forward/back not keeping the data has thrown me a little. I have quite happily been doing that all along (even when I was on a PC I think) without any problems... just hit 'Preview' then the back button and the form was still there and it didn't try to refresh. Is that what you did Sam? I'll have to delve into the caching code somewhat if this has been an issue for people.

Peter

16. Posted by Hien (Moderator 3906 posts) 12y

Hi Peter,

I'm not saying that the current validation is not working. It is working and I think it's good to have a server-side validation. However, I think that validating locally in the browser first is somehow "better" to complement the job.

If a form is to be sent to the server to be validated and then being returned to the compose page together with an error message telling you what has gone wrong, wouldn't that be actually increasing the server load and bandwidth usage? If the simple validation is done on the browser side first, it wouldn't have needed the server to process and resend the page together with an error message. Anyway, IMO, loading a few lines of javascript validation code is better than having to load the entire page again.

About the caching, most browsers, if not all, are smart nowadays. It can detect whether the page has changed or not. Maybe you could put an "Update Page" button on the page to let users check if the page has been updated. This way, the server load and bandwidth usage could be reduced because the browser will show the cached page instead of requesting again from the server. Perhaps you could disable the no-cache mode and maintain the expire feature so that the browser could at least be able to show the cached page during a particular browsing session.

(FYI, I am also experiencing the same problem as Sam on the back button. Me also running IE6 on WinXP.)

IMO, the reason behind "lost messages" is that sometimes, connection errors (e.g. DNS resolve error, link disconnected, etc) and clumsy fat fingers caused the page to be sent to the server erratically. When this happens, users will by reflex, click on the back button to re-submit the form. However, the no-cache mode has prevented the browser to display what was being shown previously. Instead, it reloaded the page from the server again, thus the blank form.

So, I think it would help in these situation if you could disable the no-cache mode. Perhaps at least disable it on the message compose pages only.

As for the message exceeding the limit allowed, it could be controlled on the page itself without having to bother the server to check. Again, it's using javascript. ;) It's a very short code and will not take up much bandwidth as it's only loaded on compose message pages.

--
Hien

17. Posted by Hien (Moderator 3906 posts) 12y

I left out something here.

On the logon case, I don't know how coldfusion session scope actually works. And FYI, If I did not log out but I have closed all browsers, I am still logged in to this site(session still active) if I open a new browser and go to this site within a short period of time. Is this how it actually works or is there something wrong here?

From my understanding on ASP session, it resets the session time-out clock whenever a page request is sent. And the session is killed if it timed-out, or executed by ASP code, or once the browsers (both parent and child) are closed.

--
Hien

18. Posted by Peter (Admin 5789 posts) 12y

Ok everyone, thanks for all your feedback.. I have come up with something that will hopefully fix all this :) I've only implemented it in the forum at this stage and will leave it as is for a few days to make sure it all works ok before using it on other forms as well.

Basically, I've replaced the way the sessions are managed somewhat and simplified it considerably. I've extended the timeout to an hour and a half (you'd have to be writing some epic to beat that surely!).

The forum entry forms have a much more powerful memory now - as soon as you hit preview, it will remember what you put in until your session expires (an hour and a half later). So even if you go to a different site and come back an hour later, you should still find your entry there ready for you to post! The memory is wiped only after the post has been made or when the session expires.

The only thing I haven't guarded against is someone who is halfway through editing a post, then accidentally hits 'destinations' or something other than 'preview' and then tries to use the back button (I'm told this wipes the form, although it doesn't on my browser). I'll look into the caching as suggested though, as this would probably be the way to fix that.

Let me know if any of you encounter problems in the next few days, in the meanwhile I'll try to get that caching fixed up

Peter

19. Posted by Hien (Moderator 3906 posts) 12y

Hmm...

Sam, it's not easy to get your brother to use javascript, eh?

Peter, thanks for the alternative way of dealing with the problems. It really helps. But I think it will only really work as how you wanted it to, by turning off the no-cache mode in these message compose pages.

I think the session thingy needs some rework. As I've mentioned earlier, it doesn't log me off if I simply close all browsers without clicking on the logout link. I can simply open a new browser later (within the timout), go to this site, and find myself still logged in. I fear that it might cause some problem if one were to check out this site in a public computer (i.e. cyber cafe), though the chances of the next person visiting the same site may be very low.

--
Hien

20. Posted by Hien (Moderator 3906 posts) 12y

Hey Peter,

I asked a CF expert on the logging out problem, and he gave me this solution (based on my explanation). I don't know if it would work because he has not seen your code. However, I really hope it could help you.

Put this in your Application.cfm page:

<cfif IsDefined("Cookie.CFID") AND IsDefined("Cookie.CFTOKEN")>
<cfset Variables.cfid_local = Cookie.CFID>
<cfset Variables.cftoken_local = Cookie.CFTOKEN>
<cfcookie name="CFID" value="#Variables.cfid_local#">
<cfcookie name="CFTOKEN" value="#Variables.cftoken_local#">
</cfif>

This will log the user out when they close the browser.

--
Hien