Re: [PHP] Re: Beginner Sessions Question
On Tuesday, July 2, 2002, at 04:31 PM, Richard Lynch wrote: > Well, yeah, at that point all you have is SQL and Result, because the > function has no idea what that SQL is about in any given call... > > But, personally, I just don't see the point to having a function/class > do my > database work when it simply: > > Increases lines of code > Increases debugging/maintenance time > Decreases clarity of code > Reduces performance > Reduces flexibility > Increases overhead Hm. Could be. I haven't benchmarked it for performance, since in this case there will probably never be more than 20 simultaneous page requests at any given time considering the small number of users. In fact, I'm sure you're right, that performance and overhead are definitely affected. But I think you're mistaking what I said -- I don't necessarily write a function/class specifically to handle my DB work. I write my classes and methods to manipulate objects easily and organize the data, and if maintaining state by doing a database insert (or resuming state by doing a database query) is necessary, well then that gets incorporated into the class. It's not specifically a database abstraction layer, it's just an object, and most of my objects happen to get built from or stored in a database at some point within their lives. And I write a function when I find that I am executing the same code all over again in various places -- like generating a date listbox or something. The effect is that debugging/maintenance time and lines of code are decreased, not increased, and clarity of code and flexibility are IMHO much better when they are safely constrained to class definitions rather than all being in one giant script. But one thing I have learned is that everyone has a different approach to writing code, and objects may not be your thing -- that's okay. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Beginner Sessions Question
Portability between different databases makes a DB class beneficial. Then again, I stick with MySQL, so I don't bother with the extra overhead either. -Original Message- I just don't see a cost/benefit ratio that makes sense in the DB classes. I know it's a minority opinion, but I've never been afraid of being in the minority. This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Beginner Sessions Question
>But once I had moved most of my code into object methods and functions >(and therefore out of the global namespace/scope/whatever), I realized >this really didn't matter as much. In fact, for consistency and >neatness, it was better that I use only $sql or $result, since there was >only ever one query in the method or function definition, and this >terseness was less cluttering to my code. Well, yeah, at that point all you have is SQL and Result, because the function has no idea what that SQL is about in any given call... But, personally, I just don't see the point to having a function/class do my database work when it simply: Increases lines of code Increases debugging/maintenance time Decreases clarity of code Reduces performance Reduces flexibility Increases overhead My personal preference is to just: include 'connection.inc'; . . . $query = "..."; $whatever mysql_query($query) or error_log(mysql_error()); # Deal with $whatever I just don't see a cost/benefit ratio that makes sense in the DB classes. I know it's a minority opinion, but I've never been afraid of being in the minority. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Beginner Sessions Question
On Tuesday, July 2, 2002, at 03:04 AM, Richard Lynch wrote: > And, really, $result is about a generic a variable name as $i > > How about using $user_info or even $user_info_result? > > Yes, I know every example and every PHP book on the planet uses $result. > That doesn't make it right :-) I hear you -- I used to use longer names for my SQL queries -- like $user_update_sql or $filerequest_result. But once I had moved most of my code into object methods and functions (and therefore out of the global namespace/scope/whatever), I realized this really didn't matter as much. In fact, for consistency and neatness, it was better that I use only $sql or $result, since there was only ever one query in the method or function definition, and this terseness was less cluttering to my code. I completely agree if you're putting database calls into the body of a script, but if you can wrap everything into smaller scopes, it's not such a big deal. IMHO. This applies to a lot of variable names, in fact. But I agree, in the main body of the script (global scope) it is best to be descriptive. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Beginner Sessions Question
>1. I know that you initially begin the session with the session_start()
>function. Is this function required on all pages in order for the session
>variables to remain globalized?
Yes -- on all pages that intend to use sessions.
If you have a page "in between" that has no use for session data, you can
(probably) not do session_start() unless you need the variable/functions to
pass the Session ID around as part of the URL if you don't like/trust the
Cookies to maintain user identification.
Not 100% sure about it if you are using URLs to pass session ID... I mostly
figure anybody too paranoid to use Cookies is a lost cause anyway :-) :-)
:-)
>2. If you have a "process login" page, which the user is sent to after
>submitting the login information, is this page ideal to hold the
>session_register() functions to define global variables and their values?
Probably...
It may be more natural to just session_register() variables as you go, but
if there are some high-level global variables, yeah, that's a good place to
put them.
>3. Would this piece of code be good to hold the preferences of a user that
>has just logged in?
Yes, but... :-)
>
>session_start();
>$link = mysql_connect("localhost", "user", "pass")
> or die("Could not connect to database.");
>$db = mysql_db_select("users", $link)
> or die("Could not select database.");
>
>$query = "SELECT user, pass FROM users WHERE user='$user' AND pass='$pass'
>LIMIT 1";
>$result = mysql_query($query, $link)
> or die("Query was not successful. " . mysql_error());
Don't ever spew mysql_error() to the web browser. Reveals too much to
hackers.
Something like:
$result = mysql_query($query, $line) or error_log(mysql_error());
if (!$result){
die("Query was not successful");
}
And, really, $result is about a generic a variable name as $i
How about using $user_info or even $user_info_result?
Yes, I know every example and every PHP book on the planet uses $result.
That doesn't make it right :-)
>if(mysql_num_rows($result) < 1) {
> "User not found. Please try again.";
You need to echo that or something more than just have it sitting there...
Probably okay syntax-wise, but not what you intended. :-)
>} else {
> $query = "SELECT * FROM users WHERE user='$user' AND pass='$pass' LIMIT 1";
SELECT * is bad.
Figure out which columns you need, and ask for them by name.
> $result = mysql($query, $link)
> or die("Query was not successful. " . mysql_error());
> while($row = mysql_fetch_array($result)) {
> $name = $row['name'];
> $colorpref = $row['colorpref'];
> $fontpref = $row['fontpref'];
> $sizepref = $row['sizepref'];
> }
> session_register("UserName"); $UserName = $name;
> session_register("Color"); $Color = $colorpref;
> session_register("Font"); $Font = $fontpref;
> session_register("Size"); $Size = $sizepref;
>}
Problem:
If it's my first time here, and I haven't selected any color/font/size
preferences, your code may or may not "break"... It's hard to say without
knowing how/when/what you initialize by default in the SQL, but watch out
for it.
In particular, if you are not going to die() on the "num_rows(...) < 1"
above...
>
>?>
>
>I know it's a lengthy example, but I wrote it, and want to know whether or
>not that would work to load user preferences into the variables UserName,
>Color, Font and Size?
I personally would do the session_register() before the while() loop, and
then just one (1) assignment for each setting. Why assign to $name, and
then $UserName when you can just use $UserName?
Actually, I'd have the session_register() stuff 'way at the top of the page,
so I know what's "global" on this whole page. Feels "cleaner" to me. This
is a religious issue. :-)
Also -- Since you are only getting one row, why the while() loop?
Would it not make it more clear that your code expects one, and only one,
row if you used no while() loop and did:
list($UserName, $Color, $Font, $Size) = mysql_fetch_row($result, 0);
Or use the mysql_fetch_array() and four assignments if you like that better,
but get rid of the loop that will never, ever, really be a loop.
And in the end, there can be only one.
If you are enforcing unique usernames in the SQL and in other parts of your
application, shouldn't your PHP code reflect that business logic, and be
distinct from a while loop that could potentially spew out 100 records? I
think it should. But maybe I'm just being too preachy :-)
>That about does it for this installment of PHP Session Questions. Please
>reply directly since I'm on the digest!
Note that some of these comments are strictly on "style" and are arguable.
I've tried to note them as such or frame them as possibilities when that was
the case.
I suspect other posters will comment on my comments and explain how "wrong"
I am on those parts. :-)
--
Like Music? http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
