Not sure I understand what you mean with exceptions.

If the secure returns true or false, how would I then get the secured string from it? .. Sure I can secure $this->query_sql, but still..
It's a good idea though, I just need to know more about how to do it before I'll edit!

__________________

What I mean is that you are using exceptions to control the flow of your class which shouldnt be the case. You should only use exceptions when you want to throw an major error.

Infact you are doing the complete opposite of what exceptions are supposed to be doing:
A very good example is the "new" keyword in c++. When you allocate memory in c++ you can wrap it in a try/catch block and catch the std::bad_alloc exception. In this case where memory can not be allocated, your program will probably end abrubtly (ie, if you dont catch the exception) and even if you catch the exception, its pretty much your chance to exit out gracefully.

Another very good example is divide by 0 exception..Another one is stackoverflow exception. When these things happen, your program just can not continue.

In your case (the secure function for example) does not create a major error. You can handle in gracefully because its not an error. Imagine if you recieved a bad SQl query and everytime your program had to exit out because of it. You can simply prevent that by returning true/false and still keep the flow of your program.

Regarding your second concern about returning the new striing you have two choices:

1) modify the query that the class instance already holds. There's absoluetly no need to have a bad query in memory. The secure function should change the field to the new query and return true/false.

2) return empty string. Not as gracefull as true/false and I am not sure how PHP will parse an empty string in an if statement but its another option.

I agree on the second concern. But how would I solve the first concern then? And does everyone else think that I shouldn't throw exceptions?

__________________

I'm going away tomorrow to Florida for 10 days. Will be back the 13th, and back to business the 14th.

I will however, have internet there, so I might check out TalkPHP sometime.
Feel free to update the class if you're in desperate need of a fix!

See you!

__________________

How soon can you finish the SQL class, we need that asap.

And I stand corrected to masfenix, we probably should not use exceptions as I have instructed use.

__________________

Well, I can finish it whenever I get an answer about what exactly it is you want to be done.

As I've understood it, you want;

1. Have the secure function secure private $query_sql and return true or false.

2. Remove exceptions wherever they aren't needed; Which is exactly where, just to clarify?

__________________

1. Not exactly, I want a generic function the SQL cleans the variable passed in its parameter and returns it.
2. Exceptions are only needed in places where the program would otherwise crash, we probably don't need to use any right now. PHP is for the most part lenient, unlike most computer programming languages which are completely not.

__________________

2. Okey! So I'll remove all the exceptions, and return false instead.

1. But that's how the function works right now? It cleans the variable passed in the parameter, and returns the cleaned variable?

__________________

Then we are done for now, put the code into the SVN repository. We really need your class before any significant development can take place.

__________________

Another thing that would be good if you could change is the comments. Comment the purpose of the variable/function, but why restate the parameter list? Parameters are just as easy to read as is opposed to in a comment. What really needs to be commented is are the commands. I honestly had a hard time understanding a few parts of the class, comments on the purpose of that part of the code would have made things a lot easier.

I will establish a commenting convention in the next few days, but just stick to the theory that comments are made to state the non-obvious and nothing more.

__________________

Sure, I'll edit the exceptions, and that.
If you have a hard time understanding, read the first post in this thread for now, and I'll write more .. explaining comments later. Though, the parameters comes automaticly when I create a commentblock above my function in Zend, so that's why. And also I've seen other people use that, so I thought why not. I'll update the explaining part though.

__________________

Class updated.

- Removed all exceptions
- Wrote alot of long comments to help you understand the class better

__________________

This probably sounds silly, or at best impractical, but how about having the ability to change the database driver that we're using? At the moment we're completely tied to the standard mysql_* but what if we wanted to use MySQLi or perhaps PDO with MySQL or SQLite?

A good suggestion. Should I add it like a prefix?

private $prefix;

And then have it assigned at the setHandler.
And a function to change, which would automaticly trigger the disconnect, then connect again using the new prefix ?

I'm not exactly sure if all the databases uses same commands cause I've only used Mysql.

Mysqli, do they have it like mysql_connect, but using mysqli instead of mysql: mysqli_connect ?
And how about query, and array, do they all use the same command, just a different prefix?

__________________

Here are some of the relevant PHP Manual pages:

• MySQLi
• PDO MySQL
• PDO SQLite

In brief, no they do not simply have the same function names with different prefixes. They take a more OO approach than the basic mysql_* functions.

Okey, after reading about their functions, I see why you thought it would sound silly or impractical. Indeed, it would be very impractical to have mysqli option in the mysql DB object. However, I've done a DB factory class, which would let you create a db object based off of what db you want, like:

$db = DB::getDatabase('mysql');

and it would then create a new DBmysql and return the instance.
It would then be easy to create other objects, such as DBmysqli, DBmysql_PDO, DBsqlite_PDO, etc.

But that's only if you guys want it. However, I think Orc will have to change the __construct in his class since it's checking if the class is an instance of DBmysql, and I don't know if someone else has done something using this class that would be affected by this change.

I would however be happy to change it, if you want.
And by "change it", I mean create the factory class.

__________________

I don't see a huge advantage to this, so I don't think we should modify that in right now. We need this class to get things moving, almost all of our further development requires database interaction. So I won't rule it out in the future, but a case will definitely have to be made to convince me it's a good idea.

__________________

I think the class is done for now, could you svn it in?

__________________

Yea sure! I'm just having troubles connecting to the SVN :S

In tortoise, I used the Repository Browser, and I checked:
http://code.google.com/p/talkphp/source/browse/

It just gives me this:

__________________

Regarding the SVN problems, read http://code.google.com/p/talkphp/source/checkout for instructions except the path to Phlox is https://talkphp.googlecode.com/svn/phlox/trunk/

Kind of related to my previous posts, is this project indended to be a distributed software like Gallery or a centralised application like Flickr?