Before April 1st starts
Posted on 2005-03-31 20:14:12 EEST.
I made few important changes in midgard-php extension , and in core header files. ( I still wonder why we have internal.h file , while it is used everywhere and simply all structures from this file could be in midgard.h file, which could make life a bit easier )
Midgard 1.7 release is going to be the first one since 1.4.x when we change dependencies for midgard-core. The most important change is that midgard depends on glib libraries >= 2.6 while we used glib 1.2.
Now, midgard may use ini like files to configure database, host , blobdir and all data which are still configured with Apache directives.
In my case , directory config is /etc/midgard/conf.d ( --prefix=/usr ). There is no special convention to name files in conf directory. When you call mgd_config_init("amerigard") you want to initialize midgard from /etc/midgard/conf.d/amerigard file.
Unfortunatelly , all files ( especially with passwords ) stored under /etc directory should be readable only for root. And any user is not able to initialize midgard from command line. Now it means:
A good point is that we could use the same configuration file for Apache vhost ( let's say MidgardConfig directive ), command line php , datagard, repligard, and more. If this is going to be a good way of midgard configuration , we should add another one ( only one ) config file where all default global variables are stored, like blobdir , or schemafile. At least, there is no need to specify blobdir , schema or even parser if one wants to follow defaults.
If I write about midgard-php I must write about two new methods ( for every object )
By default used for objects of the same type.
'Parent' doesn't mean parent object whcih is extended. It means parent in tree ( like article->topic ).
You can define parent and some tree data in schema.
You can also wonder why we need two parameters for this function when we could use only one , root's one.
This is often ( I think ) when you check if object is in tree before you get it. In our case we just need to initialize
empty object , only to let midgard-core knows what table should be used.
It means that I need to rebuild midgard packages for debian and sing a song "catch me if you can" ;)
Midgard 1.7 release is going to be the first one since 1.4.x when we change dependencies for midgard-core. The most important change is that midgard depends on glib libraries >= 2.6 while we used glib 1.2.
Now, midgard may use ini like files to configure database, host , blobdir and all data which are still configured with Apache directives.
[Database]It is enough to call
#Database host ( 'localhost' by default )
Host=
# Name of the database
Name=
# Username for user who is able to connect to database
Username=
# Password for username
Password=
# etc etc
mgd_config_init("filename"); to initialize midgard in command line php. File passed as parameter to this function is searched in "/etc" directory which depends on prefix defined for midgard-core.In my case , directory config is /etc/midgard/conf.d ( --prefix=/usr ). There is no special convention to name files in conf directory. When you call mgd_config_init("amerigard") you want to initialize midgard from /etc/midgard/conf.d/amerigard file.
Unfortunatelly , all files ( especially with passwords ) stored under /etc directory should be readable only for root. And any user is not able to initialize midgard from command line. Now it means:
- initialize midgard only for installation purposes
- run as root and do not blame anyone when something wrong happens
A good point is that we could use the same configuration file for Apache vhost ( let's say MidgardConfig directive ), command line php , datagard, repligard, and more. If this is going to be a good way of midgard configuration , we should add another one ( only one ) config file where all default global variables are stored, like blobdir , or schemafile. At least, there is no need to specify blobdir , schema or even parser if one wants to follow defaults.
If I write about midgard-php I must write about two new methods ( for every object )
$object ->is_in_tree(int rootid, int id);Checks if object with id id is in object's tree with id rootid.
By default used for objects of the same type.
$object->is_in_parent_tree(int rootid, int id);Checks if object with id id is in parent object's tree with id rootid.
'Parent' doesn't mean parent object whcih is extended. It means parent in tree ( like article->topic ).
You can define parent and some tree data in schema.
<type name="NewMidgardArticle" table="article"There is no need to define which table is used by parent. It is defined in parent's iself definition.
parentfield="topic" parent="NewMidgardTopic'">
You can also wonder why we need two parameters for this function when we could use only one , root's one.
This is often ( I think ) when you check if object is in tree before you get it. In our case we just need to initialize
empty object , only to let midgard-core knows what table should be used.
And in other news
Adam Conrad ( php debian packages maintainer ) disabled ZTS in debian packages.It means that I need to rebuild midgard packages for debian and sing a song "catch me if you can" ;)