Re: [Phplib-users] Odd PHPlib WebApp Problem
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
Re: [Phplib-users] Odd PHPlib WebApp Problem
|
From: Andrew C. <ph...@ev...> - 2004-05-10 19:59:48
|
Nathaniel, I agree with your assessment. I was hesitant to post but, thought I would, just in case it was something well-known to which I was not privy ... and it did garner insight into a better approach for nested templates from Layne Weathers. The users with the problem are all on broadband but, with different providers in different parts of the country. I'm not sure what code I could post that would be relevant. The page does use PHPlib Authentication but, that seems to be working fine, for the most part (there are periodic complaints from users about being dumped back to the login screen but, I think it is typical for users to not understand about system time-outs, not using their back button after logging out to try to do something else, etc.) The users all have AOL software installed but, are not using them for dial-up service or using the AOL browser to access the application. Your comment about caching a static version of the page made me think of something: I am going to have one of the troubled users try loading a static version of the page to see if that makes a difference. If that loads, maybe the problem has something to do with the timing of how the data is being sent. Anyway, thanks for the response. Andrew Crawford ph...@ev... At 09:26 AM 5/10/2004 -0700, Nathaniel Price wrote: >On 5/7/2004 10:26 PM, Andrew Crawford wrote : >[snip] > >>However, now, around 10-15% of the users cannot load that view. When >>they try, they get a blank page (view source shows >>"<html><body></body></html>"). >> >>The system also has a search feature that uses the same script and >>outputs the same view but, with returned records limited by the search >>parameters - generally, 10-40 records instead of the full list of >>~600. The users who cannot see the full view CAN do a search and see the >>results set. >> >>It doesn't seem to be browser-specific. I have tested on more than a >>dozen different browsers on three platforms here and cannot reproduce the >>error. I have been able to verify the problem on a couple specific >>users' systems using remote-control software and confirmed that they have >>the same issue in IE and Netscape Navigator. It sounds like it will be >>cost-prohibitive to do any major re-installations, re-configurations, or >>system swaps on the user end to try to determine whether the problem is >>specific to the configurations of those machines or to their service providers. >> >>The users like the full list view for a number of tasks and aren't really >>gung-ho to have me break the results table up into multiple pages (which >>seems like the surest, quickest fix). However, I am hard-pressed to >>explain why more than 1/10th of the users are unable to load the page >>with the new display code. >> >>Has anyone run into anything like this? Any guesses about what is >>happening or how to stop it from happening? > >I can't be sure without more details about what your setup is, but I don't >think it's a problem with PHPlib. If I were to hazard a guess, it sounds >like there might be some sort of transparent proxy between you and your >clients that might be causing problems. > >Again, I can't offer much more specific help than that. If you'd like to >send some example code or something (Do you use PHPlib authentication on >this page?), or describe in more detail how the users connect to the >server (i.e. from a local network? from the internet? dial-up? broadband? >Major service provider, like AOL?), then perhaps we could help you more. >Otherwise, your best bet would probably be to either break up the table >into multiple pages, or maybe try cacheing the results into a static html >file every so often and having the users load up that instead. > >-- >___________________________ >Nathaniel Price >http://www.tesserportal.net >Webmaster |
