From: Mitra <mi...@ea...> - 2003-02-10 08:30:08
|
I lost track of whose edits ended up in CVS, but I still see problems in sites with actions being duplicated. - Mitra At 1:44 PM +1100 11/1/03, Mitra wrote: >The code sending spot_id seemed to work,it wasn't being reset from >the session variable, because I no longer registered r_spot_id with >the session, but your way also works. > >- Mitra > > >At 12:45 AM +0100 11/1/03, Honza Malik wrote: >>Hi Mitra, >> >> I'm the coder of site module so all the the laments let go on my >>head. I'm agree it was not happy decision to have spot_id in session, >>but it is quite easy to fix. I will do it, when I will find a time. >> >> As I see you tried to fix the problem by sending 'spot id' whenever >>you send data to the server, which is good solution, but probably not >>working if you are sending the r_spot_id variable. r_spot_id variable is >>(like any other r_* variables) session variable, so if you send it by >>GET or POST, it is reset in init_page.php3 from session. >> >> I fixed the code (to send site_id instead). It is in CVS. I test it >>just for a while, but it looks it works. Please test it, if you can. >> >> Regards, >> Honza >> >> >>On =DAt, 2003-01-07 at 01:11, Mitra wrote: >>> There is definately a nasty bug in the site editor, its doing things >>> like overwriting the wrong Spot during an edit etc. >>> >>> I'm suspecting its got something to do with the session variable which >>> stores the spot id, although I'm not doing any of the obviously bad >>> things to do when someone is using session variables (like using Back >>> or Forward). >>> >>> <FLAME> >>> What I fail to understand is why whoever coded this (it isn't signed) >>> used a site variable in the first place, this information could EASILY >>> have been incorporated into the URL without the inherent bugs of >>> session variables. >>> >>> Just to be clear - in case you don't know why session variables are a >>> BAD idea, >>> If I do something to change the spot I'm looking at, and then hit >>> Back, then my browser thinks I'm on one spot, while the server thinks >>> I'm on another one. >>> >>> Its fine to use Session Variables to cache stuff like authentication >>> but NEVER use them for maintaining state that changes between screens, >>> you'll get caught time and time again because the web was never >>> designed to work with a one-way flow. (Believe me, I was at the >> > meetings where this was discussed, and a primary design goal of the >> > web - unlike the existing database systems around at the time - was to >> > make it stateless, and therefore able to branch, go back and forth >>> without talking to the server, and be bookmarkable) >>> >>> I'd love whoever wrote this code to say something ..... before I go >>> and poke around in the code, at this point my temptation is to just >>> rip out the session variable code from this module ! >>> >>> </FLAME> >>> - Mitra >>> >>> >>> -- >>> Mitra Technology Consulting - www.mitra.biz - mi...@mi... >>> 02-6684-8096 or 0414-648-0722 >>> >>> Life is a Mystery to be Lived, not a Problem to be Solved >>> >> >> >> >>------------------------------------------------------- >>This SF.NET email is sponsored by: >>SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.co= m >>_______________________________________________ >>Apc-aa-coders mailing list >>Apc...@li... >>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > >-- >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 >Life is a Mystery to be Lived, not a Problem to be Solved > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com >_______________________________________________ >Apc-aa-coders mailing list >Apc...@li... >https://lists.sourceforge.net/lists/listinfo/apc-aa-coders -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |