A wiki

I installed Yet Another Wiki for PHP earlier today. So I’ve now got a wiki at wiki.morrdusk.net. I figure I’ll use it for various notes and stuff.

In the wiki I made an Ismo area where I’ll keep ismo related stuff, for example the manual, to make it easier to update it.

Yawiki is nice but it needs a serious URL clean-up. I don’t know if it’s just me but I find URL:s like index.php?area=Foo&page=Bar totally horrible. So I hacked the code to produce URL:s like wiki.morrdusk.net/Foo/Bar instead, but what I did was an ugly hack. What yawiki needs is proper support for better looking URL:s, hopefully that’s something planned for the future.

Please let me know if some part of the wiki is broken due to my messing around with the code.

Update: It’s using a totally horrible table based layout as well. So you’ll have to live with the wiki looking different from the rest of this site until I’ve had the time and energy to create a custom theme.


It’s about time that PHP gets something like PDO, now someone just needs to write a PHP version of Java’s pBeans, a really cool Java based Object/Relational (O/R) Mapping Layer, and PHP might have a future again.

The mess that is PEAR

Have a look at the recent SCM_SVN thread on the pear-dev mailing list, for example this post and this post. I guess this bureaucracy mess is the beginning of the end of PEAR. How can they expect people to want to continue contributing to PEAR if doing that means fighting a constant up-hill battle, I especially like how people who have not looked at the proposed SCM_SVN code nor the Horde_VC code, tell Clay that he should merge his work with the Horde_VC package, not even considering that any merging is most likely impossible and it would basically mean dumping all the SCM_SVN code down the drain and re-code everything again for Horde_VC. If that is not discouraging I don’t know what is.

What is in it for Clay, he already has working code he’s using, so why should he redo it? Nor is anyone stepping up to take care of PEARifying Horde_VC, so it wouldn’t surprise me if PEAR ends up without any version control package at all. It would be another thing if some of the people doing all the talking would actually say they would take care of the Horde_VC package, but expecting Clay to give up all he has done so far and do it all over again, they’ve really got some nerve there…

I think this is the thing that will ultimately destroy PEAR. People should not be discouraged when they want to contribute to PEAR, they should be welcomed with open arms! People willing to give up their free time to an open-source project don’t grow on trees, that is important to remember.

There was also this thread a short while ago, which raised some of the same issues. Of course, no solution or conclusion was reached, for some reason things related to PEAR are often left hanging unresolved, I guess people wish that left that way the issues will be forgotten. Maybe what PEAR needs is a strong leader who people would listen to and respect. The current situation has shown that it is not working.

Showing RSS feeds with PHP

I thought I would share the small script I made to generate my latest links from del.icio.us in the right sidebar on morrdusk.net. Shows how easy it is to display RSS feeds using PEAR’s XML_RSS package. Just remember to htmlentities() the output if you want the web page to validate.

The RSS file is retrieved every 30 minutes by a cronjob and stored in the local filesystem.

Update: I removed the code, email me if you want it.

Ismo Core’s AOP support is getting ready

When finishing up the AOP (Aspect Oriented Programming) support, well actually it’s only support for Interceptors, in Ismo today I came across a slight problem.

I’m using a Dynamic Proxy to proxy the calls to the state class which calls possible interceptors that should be applied. The dynamic proxy uses PHP’s overload extension (I can’t understand why it’s called overload) so that all method calls on the proxy will go through the special __call() method.

This works out fine unless the class the proxy is a proxy for starts calling methods on itself. Because those method calls are done on the real class and not the proxy the interceptors won’t get applied. In Ismo’s case that’s a slight problem as the state classes have a method called execute() which determines the right action method to call, and then calls that method. One big point with implementing support for interceptors is to be able to apply them to the action methods, and now that doesn’t work.

However, I’ll solve that for now by doing a custom execute() method in the proxy, so that the execute() method in the state class won’t be invoked and hence this won’t be aproblem. It’s an ugly solution, but it will have to do for now. In the 0.3.x series of Ismo_Core I’ll correct it the “right way” by refactoring the state classes and action methods. I’ll start by removing the dispatching logic from the state class and create dispatch classes which will handle that part. This will also make it easier to support action classes a la this discussion on the sitepoint forums.

The tricky part is how to map the request url to the right class in a mixed configuration, with some action classes, a couple of states using action classes and finally some states using traditional action methods. It starts to get hard to have some kind of automatic mapping based on the url, but I also want to avoid going the XML configuration way, so I don’t know. I’ll have to ponder this a bit more…

Any bright ideas?

Ismo_Core 0.1.3

Version 0.1.3 of Ismo_Core is now available, the following changes have been done:

  • (2004-01-13) Fixed Ismo_Core_Filter::filter() missed to change the method signature last time.
  • (2004-01-13) Ismo_Core_Application::setStateLoader() now takes the loader class instance as a reference.
  • (2004-01-20) The action and show methods now have pre and post methods. Suggested by Fabien Franzen. And a manual entry exists for this feature.
  • (2004-01-28) Moved the state loaders to Ismo_Core_Loaders.
  • (2004-01-28) Added the loaders and getting started manual sections.
  • (2004-01-28) The follow attributes added to the Ismo_Core_Request class:
  • _defaultLocale
    and the follow methods:

    Ismo_Core_Request::getLocale() has been fixed and Ismo_Core_State_HTTP::execute() now calls deduceLocale() which means that the current locale can be determined by looking at the _locale attribute in the state classes. Thanks Fabien Franzen!

    Next I plan on finishing the AOP support.


The PHP and PEAR people seem to finally have figured out that it would be useful to have a PHP equivalent of javablogs. Let’s hope it works out! I would love to see a more concentrated location for PHP related information and discussions.

There is also phpcommunity.org, will be interesting to see what becomes of that.