PHPUnit2 3.0.0alpha11 released
posted: June 14th, 2006 · by: Sven
Wow :) Sebastian Bergmann finally added Mocks to PHPUnit2 which has been released as 3.0.0alpha11 to PEAR. The changelog reads quite interesting and comprehensive.
Howto get PHPUnit2 talk to a browser
posted: January 22nd, 2006 · by: Sven
Ok, I admit it took me a while to figure out how to run a PHPUnit2 testcase via http rather than cli on a Windows box.
First thing I needed to understand is that PHPUnit2_Util_Printer::__construct() sets fopen(‘php://stdout’, ‘r’); as output stream by default. This won’t output anything, so one has to advise the printer to use php://output.
Next thing was that I started the TestRunner by run(). Wrong way … this instantiated a new PHPUnit2_TextUI_TestRunner object and my output stream was send to nirvana.
The following works though:
$suite = new PHPUnit2_Framework_TestSuite();
$suite->addTestSuite(new ReflectionClass('MyTestCase'));
$runner = new PHPUnit2_TextUI_TestRunner();
$printer = new PHPUnit2_TextUI_ResultPrinter('php://output');
$runner->setPrinter($printer);
echo '<pre>';
$result = $runner->doRun($suite);
And don’t tell me to rtfm. I’ve found no docs on this. Nothing. I don’t think there are any. :(
Access level constrains in php5 really suck
posted: January 4th, 2006 · by: Sven
I can’t understand why I’m being forced to keep the access level of a class’s method when I extend it.
class SomeFactory extends PEAR_Delegator {
protected function __construct() {
}
public static function instance() {
}
}
... would make perfectly sense IVHMO. But it throws …
"Fatal error: Access level to ActivePdo_Relation::__construct() must be public (as in class PEAR_Delegator)"
What’s the reasoning behind this?
That’s because I’m “doing something terribly wrong”, is it? Not the “php way”? Boy, this sucks.
php namespaces design
posted: November 18th, 2005 · by: Sven
I’ve done a quick theme for the phpnamespaces.org wiki, which is driven by DokuWiki and came with the default skin so far.
Read the rest of this entryStatus of patForms/Propel integration
posted: October 15th, 2005 · by: Sven
It’s been quite a while ago since I’ve posted about the power of patForms and Propel – once integrated. In the meantime there’s some work been done in both codebases to make this possible.
Here’s some update about the changes and the SVN repositories of these projects.
Read the rest of this entryPropel and patForms integrated: powerful form generation
posted: May 3rd, 2005 · by: Sven
Propel is a php object persistence layer that enables you to:
- generate an xml database scheme from an existing database,
- generate ORM object and peer classes from this scheme and
- then already use these classes as a (part of the) model of your application
Propel lets you describe and configure in detail how your classes are to be build. You can define validatiors for example, against which you can check your objects before you save them to the database. And you can define foreign key table relations and resolve them in a really simple manner.
The form generation toolkit patForms on the other side comes along with lots of capabilities to create flexible forms, nicely separated into layers by design and easily extensible. patForms itself provides ready-made form validation rules, tools to populate form elements like Select boxes from Datasources and much more.
Plugging these both tools together makes up a powerful combination.
Read the rest of this entryA Php userland Dom Contest
posted: April 6th, 2005 · by: Sven
Now that we’ve seen that php5’s dom extension really lacks support for php’s own un/serialize()ation let’s have a quick look at some php implementations of XML Dom. Possibly, we can speed up our templating experiment’s performance by using a serialize()able XML implementation, so that we’re able to cache our components and ressurect them from an already ready-made, fully usable state?
We’ve done an internal, purely subjective mini-con/test with some php Dom implementations that were spit out by Google. It has been a veeery superficial search (so for sure there are more implementations out there) and it has been an even more superficial test setup (so for sure there are some tweaks to tune up performance for one or another implementation).
Probably, that’s interesting. So here are the results.
Read the rest of this entryWhy php5 DomDocuments need to be un/serialize()able
posted: March 2nd, 2005 · by: Sven
In our last post about “Template playing with php5’s Dom” we shared some thoughts about how to build a basic templating engine based on php5’s build-in dom extension. I have been playing around with that and have to say I found php5 dom’s lack of being un/serialize()able really annoying.
Why would anyone want to php un/serialize() a php Dom tree? A dom can be “serialized” to Xml, that’s human readable and non-proprietary! Creating a DomDocument and getting some Xml parsed is fast.
So, what the *%#~ is this about?
Ok, let’s take a minute to investigate that. Here’s an answer.
Read the rest of this entryTemplate playing with php5's Dom
posted: January 15th, 2005 · by: Sven
Standards, standards, standards … just had a look into Jeffrey Zeldman’s “Designing With Web Standards” (again). He’s nearly religious, but absolutely convincing and insightful about why we all should use web standards. You have to read it.
Ever thought about the role that standards play in the php world? To me it seems obvious that the php world definitely lacks a templating standard.
There are countless php template engines out there, each one introducing some own nifty template language, template tag syntax or something equivalent. What would php’s template world look like, if all this programmer’s manpower was concentrated by the presence of a standard (or at least: some strong recommendations)?
But wait. php5 comes along with a fine, build-in XML DOM extension. Isn’t that a standard? Indeed, it is.
Let’s have a look at how we could get started with a templating system bootstrap using that stuff.
Read the rest of this entryLet your classes live their own life
posted: December 27th, 2004 · by: Sven
Comparing Google’s results on querying “php event listener” with “java event listener” we could state: so far there’s not too much about events and listeners, observers and notifications in the PHP world, while these basic patterns have gained safe ground in Java, C++, ... for many years.
Thus, it’s no wonder that we’ll find matured Lifecycle implementations in the Java world like in JavaServer Faces, Geronimo, WebWork and others more. Afaik, there are some efforts on event driven application design in the PHP world though, some examples well worth to study are: WACT, Prado, Poseidon.
In this article we’ll examine how to implement a simple Lifecycle in PHP.
Read the rest of this entryA php way to simple class aggregation
posted: November 30th, 2004 · by: Sven
Well designed OOP is all about code reuse, robustness and self-containment. But a programmer who’s played around with an OOP language longer than a few hours will soon notice that things are not that simple as beginners are being told by OOP tutorials. This article is about a php way of achieving a clean separation of code and enabling the programmer to plug & play classes into others at the same time.
Read the rest of this entry