Archive for the ‘Uncategorized’ Category.

Every current and new php framework, ever.

Here’s a (dramatized) conversation between a mere mortal php developer and one of the developers/gurus/ascetics/nerds that wrote/uses/has marital relations with a current or upcoming php framework:

“Oh, you want a database connection? First, create the Query object by accessing the GetInstance method of the DIC, then use the GetFactory method to get a factory that you then call GetActualObject(NotReally $notreally) where $notreally is a NotReally object that contains the DIC configuration that you request from the GetInstance method of the ConfigureDIC service, which you then call GetNotReally on with the object name as an argument…”

“Why do I have to have all that before I can run a query on the database?”

“What are you, a moron? This is clearly better than having a simple, clear, intuitive method for getting something as basic as a database connection! Oh, and you want to run an *actual query*?

“Then instantiate a GetQuery object… I’m kidding, you really have to go to the GetQueryServiceManagerFactoryInstance::GetInstanceQueryServiceManagerFactory() static method (I know the order is different, but if you don’t see why, you’re an idiot and you should go back to using something like LOGO or BASIC or VB.NET, since clearly you don’t deserve to use php) in order to get the PleaseLetMeDoAFuckingQueryFactoryServiceManager object, then call the GetQuery() method to get the QueryHaHaThatsFunnyYouWantToDoAnActualQueryAndGetSomethingConstructiveDone object…

“Then you have to go to www.obscurefreakingsiteinromania.ro and search the forum for a thread that may or may not be there that has the secret formula for the order of methods that you have to call on the QueryHaHaThatsFunnyYouWantToDoAnActualQueryAndGetSomethingConstructiveDone object in order to get an object that you can build a query with. If you call the methods in the wrong order, it deletes everything on the server’s hard drive and emails obscenties to your grandmother (That’s a bug, but it’s only been open for three years, what do you want)…

“And then here’s what you have to do to run the query: Get the QueryRunnerInstanceFactoryNamespaceSessionFnord object from the DIC, which you do by calling the GoodLordPleaseKillMeNow() method on the ConfigureDICWithFlintTools object, then monkeypatch the push() php construct because the way it worked before was too simple and we wrote a replacement for it, but in order to do that you have to recompile php with the –secret-sauce-that-nobody-knows-about-because-we-are-special-and-you-are-not flag…

“Oh, and did we mention that you can’t use arrays in this framework? You have to use WhyTheHellAmIUsingThisFrameworkWhenICouldHaveWrittenItMyselfByNowInterfaceCollectionIterator object for any group of .. things.. you want to manipulate. If you try to use something like ‘$a = array();’ then we strangle a kitten…”

Yes, I’m a little frustrated.

I passed my ZCE!

On Tuesday 2 Nov 2010 I sat for and passed the Zend Certified Engineer 5.3 exam.  It was a difficult test and I’m proud of the achievement.

Generate opening <form> tag using a Zend Framework view helper (Zend_View_Helper_Form)

Sometimes you have to use Zend_Form in such a way that you’re manually laying out tags in a specific way for presentation or other purposes, and it’s useful to be able to automatically generate the opening <form> tag with the correct attributes.

In your view, do the following:

1
<?php echo $this->form('myForm', $this->myForm->getAttribs()); ?>

where you’ve previously added an instance of myForm to the view in your controller. The form tag will be generated with the attributes you’ve set on the form object (eg method, action, etc.) Then you can simply close the form tag after manually laying out whatever elements you need to.

PDOStatement returns false but there’s no error

I ran into this a little while ago but didn’t blog it, then someone I know in ##phpbartalk (on freenode IRC) ran into this again today. Cost him hours, apparently.

PDOStatement::execute was returning false, but a calls to PDOStatement::errorCode and PDOStatement::errorInfo were returning no useful information. The query in question was an insert, and no row was being inserted into the database. Clearly the query was failing, but there was no indication why.

I remembered dimly running into this myself, and looked at the php manual entry for PDO (specifically, this error handling page). Apparently the default error handling mode for PDO is PDO::ERRMODE_SILENT, which is less than helpful in this case. In the user comments, this was unearthed:

1
2
$dbh = new PDO( /* blah blah blah connection string */ );
$dbh->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );

Turns out that it was a malformed query (dropped a trailing parenthesis) that gave a SQL error when run manually. However, for some reason PDO was issuing a warning instead of an error, and because of the ATTR_ERRMODE, it wasn’t even issuing that. Less than helpful, but I’m sure there’s a reason for the default behavior. What it is.. well, someone can enlighten me on that one. I’d sure like to know if a query were generating an error…