$dbn = new PDO("mysql:host=".$this->hostname.";".dbname=$this->dbname, $this->username, $this->password);
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Thank you NogDog , the problem is not in the connection , it is ok and working very good with cocatenation or not , the problem is "
how to assign this connection variable (object) to the local variable $conn ??
I don't see an obvious problem, though perhaps we're not seeing everything in context? How about simply assigning it from the get-go:
PHP Code:
$this->conn = new PDO(...etc...);
...?
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Hi,
first of all, constructing PDOs is still experimental, even as for the most recent PHP release.
As I GUESS, you use some get/post/and/or/global stuff to init the Constructor. If you do this, what do you need a class for?? Mixing up straight procedural programming and OOP doesn't work (it never did).
Pass all member assignments as arguments in the constructor, and the whole code works.
__construct(/** @var char*/ $host... bla bla)
$sql = "SELECT * FROM tab_idents-users";
$query = $dbn->query($sql);
foreach ($query as $row)
echo $row[1];
$this->conn = $dbn ;
echo('reached end of constructor');
}
}
// test it here
$pdo = new pdodb(...);
Depending on your environment, it is pretty clear that (before end of Construction) you may or may not encounter assignment problems as long as u work with "global" stuff instead of (adhering to classic OOP rules) CONSTRUCTING a class.
Hi ariell
Im passing to the constructor an array of variables which is comin as an object of a registry class containing a lot of variables (all the application startup variables) ,so , inside the pdodb class I did extract the variables that I need .. (the database configuration parameters), what have I did wrong ??? where is the mistake
can u publish the entire code? At least the part that is invoking your class' Constructor as well as the WHOLE Constructor itself (thus with all arguments).
OR: Do u read something like an $_ENV or $_SESSION var inSIDE the Constructor?
However, the mere fragment is not enough to tell why an error might occur, it's more of a guess.
Moreover, why don't u take a more "traditional" approach, meaning not playing around with something instable such as PDO (still) is?
Hi again ;
Im trying to use a light MVC framework , where in which all the startup variables saved in an object of a registry class. this object will be sent to the controller , this is the controller code
PHP Code:
class Controller_Members extends Controller_Base {
function index() { $filepath = $this->registry('dbconfig'); $pars = $this->getPars($filepath); $db = new pdodb($pars); $users = $db->getUser(); $this->view('template',$users) ; } }
Note that the registry object been processed in the parent class.
the getPars method is the function that aim to open a system file (config.ini) and bring the database only configurations .. there are no post or get variables as you see..
what I did to solve this issue is using a singleton pattern to get an Instance of pdodb class ,, and it is working now.
but I want to know for education purpose ,, what is the wrong with my code ....
ariell .............. why Pdo in unstable , what alternative you recommend ??
PDO being unstable, at least: experimental, is said to be so by ZEND. I don't know whether this is an official thing, but (since living most of the year in Tel Aviv) I have some friends with Zend, and we're talking pretty often about PHP design issues.
As for an alternative, this is not easy to put. In general, "MVC" at first glance sounds very nice, but a (so called) model-view-controller approach is actually impossible to implement with "pure (no, not poor...) PHP. Whether the ZEND guys like to hear it or not: PHP has been, still is, and (most probably for a long time) will stay a PROCEDURAL language, so component development (which is what actually stands for "MVC") is a) tidious and b) not fully implementable.
- Alternative: With the rise of release 5 (thus as PHP started to show up with real OOP patterns, such as encapsulation thru different access methods, etc.), I developed my own "framework". I preferred this to using that (oversized and slow) stuff like PEAR (and PDO). For two reasons: One is SPEED, the other is my need to KNOW what's going on within "my" objects. This framework is actually nothing but a simple a class wrapper around all those thousands of proprietary PHP-functions, but it allows for some abstraction. PART of this framework is the DB handling. I suggest u do the same. That way you can use those fast mysql_XXX, psql_XXX and whatever functions, NEVER re-coding, NO MATTER where this stuff is running on as long PHP5+ is installed.
Mine is split as follows, and maybe you like this "componenting":
1) xaSql - abstraction layer, returning appropriate grammar for (currently) MySql, PostgresSql, Oracle, IBM DB2 and SqlI.
2) xaSqlQuery - manages ALL query actions
3) xaSqlConnection - manages ALL db (persistent/simple) connection issues
4) xaSqlTransaction - transaction abstraction layer, necessary, because PHP (actually) does NOT support transactions (which, by the way, in 2008 feels like a bad joke)
5) xaSqlCondition - ...self explaining...
6) xaSqlStateDescription - necessary to "get away" from stateless web applications
7) xaSqlCol, xaSqlRow, and xaSqlTab - representing an (abstract) view of, as the name says, columns, rows, and tables, and
8) xaSqlCommunicator - the glue that stands for any DB access' business logic.
In the beginning, this looks like a lot of work, but it pays out. Never ever worrying about drivers, different syntax, certain (non-)support, and so on. Also, instead of writing hundreds of lines of the same code just because of one or two small differences, you need three or four lines, and this is it.
Again, the only REAL alternative is: use a REAL programming language, which is, as we know, not always possible if that's aboput the internet...
I'm not sure, I think it's not ripe yet for a BETA (if you want to put it like that). Also, the DB part is just a PART, 8 classes, all in all the framework has about 150+ classes. However, if you're serious, really interested into helping on working it out, I could set up a web-site plus CVS and give it a shot.
well , I cannot promise u ,, I like the readymade things , just plug & play ..... , but as soon as u publish your site, a lot will contribute in the project. (I think so)
I'm not sure whether you're right. a) I am a bad "team-worker". b) most people want to USE this stuff (like you), not contribute. c) the framework isn't even a year old, just on the brink to beta.
Bookmarks