Seems to me like this would generate a lot of extra server traffic, and a little confusion... The only benefit I can see is that you're getting rid of ugly page URLs.
Problems I can see: 1. sessions need to be carried around... if your user has cookies turned off, or you wish not to use them; a) the sessions will break, or b) you will need to carry the SID around in a URL So, your URLs will actually look like http://www.site.com/article.php?PHPSESSID=12413523245546453 Nothing I can see in your code/idea changes the fact that EACH INSTANCE OF A SCRIPT NEEDS TO MAINTAIN STATE (carry the session around). You have two choices: - cookies - URL - compile with trans-sid -- uses cookies if possible, otherwise uses URL I have never seen anything else work. 2. bookmarking/linking/etc... essentially what you're saying is that one URL, page.php, will do many different things (like present many different articles), based on session information... this doesn't sound to good to me... bookmarking, search engines, etc etc might all get it wrong, and certainly would make it hard for people to email the URL to a friend, or link to it from another site. You *may* want to consider the apache mod_rewrite stuff. I spotted an article on sitepoint.com about it.... erm... here we go: http://www.webmasterbase.com/article/910 Instead of: http://site.com/page.php?article=4, you can do things like: http://site.com/page.php/article/4, which are very bookmark / link / session / searchengine friendly. Just one last note... PHP sessions, by default, store the session variables in files transparently (ie, you don't have to do much), NOT a database. So, writing a script that requires sessions will NOT require MySQL. Just look at amazon, yahoo, msn, or any other big site... they just pass the sid around in URLs, and people deal with it. Learn from the "best". Cheers, Justin on 12/11/02 5:55 PM, Charles Wiltgen ([EMAIL PROTECTED]) wrote: > I posted this yesterday: > >> Specifically, I'm considering using hidden fields for persistent object >> properties because (1) I don't want cookies to be an issue, (2) I prefer not >> to have session IDs appear in a URL, and (3) I prefer not to use require a >> database just to store persistent properties. > > After Justin and Ernest straightened me out, I went back to the drawing > board and came up with a method that I call Invisible GET. > > Let's say my page is at <http://www.getsome.com/>. When I want to change > the month (for example), I... > > (1) Open <http://www.getsome.com/submit.php?month=3&; > target=http://www.getsome.com/>. > > (2) In submit.php script, I throw all $_REQUEST variables (except > "target" and "PHPSESSID") into $_SESSION variables, and... > > (3) ...redirect to $_REQUEST['target'] via header(). > > I've sure I've invented something that nobody's done before. :^P > This method feels about perfect. Users won't be seeing or bookmarking > garbage-filled URLs, and I'm not using lots of hacky stuff to achieve it. > > I wish I could generate submit.php on the fly, though -- I'm trying very > hard not to pollute the web folder with anything that I don't have to, and > file creation/deletion is very expensive since I have to do it via FTP. Any > ideas on this one? > > -- Charles Wiltgen > Justin French -------------------- Creative Director http://Indent.com.au Web Developent & Graphic Design -------------------- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
