On Sun, July 15, 2007 2:25 pm, Wesley Acheson wrote: > 1. Does the answer below mean no global persistant objects? > (Application scope) I guess that it does. Pretty much, yes. PHP is more Unix-like in quickly spitting out an answer, rather than MS-like in having some monolithic "answer" object hanging around forever. This has pros and cons, of course. Focusing on the "pros" and the "shared nothing architecture" the point is that to "scale up" you don't have to do anything but throw more servers in the web-farm. There is not single point of failure big-iron-required box that needs to grow with web traffic to hold the one big "answer" that gets bogged down under load. > 2. Is this an un-PHP way of doing things? Possibly. I couldn't even read the code posted, really, as it was too cramped... :-v > 3. Is what I'm trying to do even worthwhile or should I just create > each form and its validation rules by hand? (My gut feeling is that > its still worth doing as it centralizes form processing and reduces > redundancy on a code level) The problem with shoving all forms into one big pile is that you generally want to customize the validation and processing to such an extent the the only actual common share code for the form is, errr: echo "<FORM>"; :-) > 4. Which would be more expensive recreating the object each time? Or > fetching it from the session each time? (I know that this probably > doesn't have a definative answer) It really depends on where/how you store session data, but I suspect that doing "new x()" is way cheaper than creating sessions if you aren't already using them. If you already HAVE session data, and you are just tossing one more item into the $_SESSION array, the extra bytes is probably not all that significant. Only a test on your hardware under load will tell you for sure, of course. > Anyway my feeling is it probably shouldn't go in the session as its > not a client object. What's a client object? Don't tell me. Think about it and draw your own conclusions. :-) PS Yes, one can store sessions in memcached. Another nifty trick is to encrypt your session data, and if it's less than 4K, just make it be the value of a cookie. This cookie value will "travel" with the user even in a distributed server app. You then only need to read/write memcached for "large" session data. Some more info here: http://hostedlabs.com/ PPS Do give the PHP way a fair shot, and do some real-world testing before drawing any conclusions wrt the Java way. But if you're just going to "fight" PHP all the time and do it the Java way, just go back to Java and be happy :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
