Piotras' blog: Archive

2005-02-01 - 2005-02-28

PHP4 and mysql extension

Posted on 2005-02-04 12:38:29 UTC.

This should do the trick.

Add sources repository to /etc/apt/sources.list file.
( in my case I added Polish mirror )

deb-src ftp://ftp.pl.debian.org/debian testing main contrib non-free

Install mysql client and php4 development packages

apt-get install php4-dev libmysqlclient12-dev

Download php4 sources package.

cd /usr/src
apt-get source -d php4
dpkg-source -x php4_4.3.10-2.dsc
cd php4-4.3.10/ext/mysql
phpize./configure --with-mysql=/usr
make
cp .libs/mysql.so /usr/lib/php4/20020429/
/etc/init.d/apache stop
/etc/init.d/apache start

Point your favourite browser to http://www.cafepress.com/mgd

Find something suitable for You :)

Let me write code's part unformatted as this won't break anything.

Define object.

<type name="MidgardRocks">
<property name="name" type="string"/>
<property name="info" type="string"/>
</type>

Write testing PHP code.

<?php
$amerigard = new MidgardRocks();
print_r($amerigard);
print "<p>";
$amerigard->name = "Midgard is cool";
print_r($amerigard);
?>

Request page.

MidgardRocks Object ( [id] => [sitegroup] => [author] => [owner] => [realm] => [guid] => [changed] => [updated] => [action] => [name] => [info] => )

MidgardRocks Object ( [id] => [sitegroup] => [author] => [owner] => [realm] => [guid] => [changed] => [updated] => [action] => [name] => Midgard is cool [info] => )

You still want to ask about these all undefined properties in xml file?
This is simple. MidgardRocks by default inherits MgdRpd object which has these properties defined.
You do not really need to worry about them.

Code works , but is unstable. I need to find out if there is some other way to define class members.
If not, we need to call class constructor only when object is initialized, so by default all objects called
with new Object will be empty. I am starting to wonder if this is good idea anyway.

Error 404 , /midgard not found.

Posted on 2005-02-10 20:37:53 UTC.

This is a good moment to set Apache log level to debug. Do not try to find /spider-admin , /midgard or /aegir dir on your filesystem under DocumentRoot set in Virtual host configuration file. Instead of this , open main Apache configuration file and set log level to debug. It is set by simple directive:

LogLevel  debug

Stop Apache and start again. Request midgard page and take a look at log file.
In many cases you may find debug errors like this one:

[debug] midgard-apache2.c(1314): [client xxx.xxx.xxx.xxx] Midgard: regenerating /var/local/cache/midgard/7-57-12-0.php: cannot open, assuming non-existant
[debug] midgard-apache2.c(2253): [client xxx.xxx.xxx.xxx] Midgard: Couldn't create cache file

It simply means that one of the directory set by MidgardPageCacheDir has not even executable bit.
You should check every dir in this path. The most probably is that the 'cache' directory itself has drwx------ permissions ( the most probably for system when midgard is self compiled and with prefix other than /usr ).
Change permission to drwx--x--x using chmod:

chmod 711 /var/local/cache

Note , that we use only x bit instead of rx as we do not want Apache user to be able to list this directory.

Entry added also in troubleshooting section on www.midgard-project.org

Class , not class.

Posted on 2005-02-13 14:14:16 UTC.

While MidgardRocks class was already initialized and declared with all its members I found this class very unstable and ( frankly speaking ) far from being usefull. I must say *FAR FROM*. Why? Zend extensions idea is good , not great , but good. You can initialize module, define globals , define classes and almost anything You would like to define.
When class is registered it is stored in CG globals HasHTable, so it is available at any time while module is loaded. What about members? You can add class' members by using one of few zend_hash_add_*** internal functions, by adding members ( object's properties ) to zend_class_entry->default_properties.
OK, where is the problem?
When You add members to class while module is initialized, you should mostly use EXACTLY the same functions which are used and defined in zend_compile.c. This simply means that all data and memory allocated should be freed when request shutdown is called. Got the point? You can not add and define class' members once , cause zend needs to destroy these data. This is not wierd when you think about calssess which are defined on PHP level.
Start request, define classess , methods , members and while request is ended , free them all.
Real nightmare from extension point of view.
What makes me "funny" is the fact that class members are destroyed, while class itself is not! It doesn't matter how you define members , and which zend_hash_xxx function will be used.

The most important thing. We need real class constructor. We need object to be initialized with all properties.
We need to extend classes with all parent's properties. I think that we could use some get() method which could be
real class constructor( If Zend knows about such thing as class constructor :/ ) .

What is also interesting. Initialized objects ( think about Zend ) are mostly initialized with 'return_value' internally used by Zend. It looks like no one documented the fact that one may use 'this_ptr' instead of returned value to get
PHP's syntax like $art = new Article();.

What do we need now to make MgdSchema being very usefull with Zend ( The most difficult midgard module to be created IMO )? Looks like we need some kind of "caching" feature to initialize classes only when theses should be used. They can be defined and registered , but empty as long as you will need to use them. And we need to make this during request time. This is bad , but still far more better and faster then define classes on PHP level.
At least we do not waste time which is needed to parse PHP code.

Back