Piotras' blog: Archive

Walking the path is knowing the path

Posted on 2005-04-02 22:40:25 UTC.

I just forgot to mention about this last time , when I wrote about tree management.  All Midgard objects has invisible and not active 'path' property now.
What does it mean?
When object is created or updated , midgard library "walks" the object's tree and build it's path.  So , when we only initialize automagic database and storage creation , the path property could be added to object's table, and anyone could use already defined and set path to get object by path without any need to build it's path during ( very valuable sometimes ) request time. Articles created with MidCom may be get "outside" the MidCom and used with MidCom which makes midgard-php and MidCom much closer and almost the same midgard "extension".

Simple script

Posted on 2005-04-13 11:58:04 UTC.

OK, Midgard has new release. 1.7alpha1.
I wonder what can I do with new code and with new objects and methods ;)

First , I am lazy right now to use my favourite browser , so I will use simple plain PHP file and write some simple code.

<?php

mgd_config_init("amerigard");

/*
* I do initialize midgard internals from 'amerigard' file , which is located 
* in /etc/midgard/conf.d/amerigard file in my case 
*/

mgd_auth_midgard("admin", "password");

/*
* Note that I did not use third parameter. 
* Do I need cookie? In plain text? 
* Midgard does not send cookie anymore.
*/

$host = new NewMidgardHost();

/*
* Notice 'New' in class name. 
* New midgard types can not overwrite old ones.
*/

$host->name = "localhost";
$host->find();

/* I want to get only host objects which has localhost as name */

while ($host && $host->fetch())
{
  print "Host 'localhost' with id $host->id\n";
  $oldhost = mgd_get_host($host->id);
  $style = new NewMidgardStyle();
  $style->get_by_id($oldhost->style);

/*
* Every old object may used as new object 
* and every new object may used as old one.
*/
  print "This host uses $style->name style \n\n";
}
?>

And the output:

Host 'localhost' with id 1
This host uses Aegir_Master_Style style 

Host 'localhost' with id 2
This host uses Empty style 

Consider the fact that I run this php script as root. I may use it to setup Midgard database or even manage this database and even virtual hosts without any need to request web pages.

And some style features.

Change virtual host configuration and force midgard apache module to act like old module without caching facilities.
Let's say we have three (different ones) styles with "navi" style element, and we want get one of them during request time.
We need to use mgd_preparse function as Apache module serve page and style elements with this function.

<?php

$current_style = $page->style;
$style_a = 1;
$style_b = 2;
$style_element = "navi";

/*
* Current requested page uses style with id=3.
*/

eval('?>'.mgd_preparse(mgd_template($style_element).'<?php '));
mgd_set_style($style_a);
eval('?>'.mgd_preparse(mgd_template($style_element).'<?php '));
mgd_set_style($style_b);
eval('?>'.mgd_preparse(mgd_template($style_element).'<?php '));

/* Set style to initial value */
mgd_set_style($current_style);

/* Do more */
?>

Every mgd_set_style call forces midgard to "reload" internal style elements storage and gets all style elemements which has style field set to style id used as function parameter. This is not flexible as it should be right now , as this may be used only with "old" midgard apache module. Anyway we are closer now to ability to set midgard internals from other levels.

mgd_set_lang

Posted on 2005-04-22 19:20:45 UTC.

Reading this blog's title you may expect some lang features. Yeah, MgdSchema supports multilang.

Part of MgdSchema.xml file which describes page element.

    <!-- Multilang features -->
    <property name="value" type="text" table="pageelement_i" multilang="yes"/>
    <property name="sid" type="integer" table="pageelement_i"/>
    <property name="lang" type="integer" table="pageelement_i"/>

As you see "multilang" is set only once, and not for every property. The point is that GObject's MgdSchema data collects all "external" tables which should be used for object building functions, and when MgdSchema gets "multilang" xml element's property , sets table's internal pointer to 1 and make it "multilanged". So simply there is no need to point  every property to use multilang. You may of course add another table to object which doesn't use multilang if you really want to use more than two tables for object. Not multilanged tables support is not quite stable yet , as I started to write it on the airport,  waiting for the flight to Helsinki to join MgdSchema workshop team. ( BTW , if I am to describe workshop in only one word , I would like to use word Excellent! )

Multilang is currently usefull for object retrieval and breaks with mysql errors , when create or update method was called. Let's hope to see this fixed next week. Good news about creating objects is that we follow name rules from current midgard version.
When You do create object you can not create object with the same name and with the same parentfield. Except when name of the object is empty. It doesn't affect objects like MidgardParameter or MidgardAttachemnt. Why?
Because we define such behaviour in schema file.

<type name="NewMidgardEventmember" table="eventmember" parent="NewMidgardEvent"
 parentfield="eid">

Set eid property ( or eid field in table ) as parent's one.

<type name="NewMidgardParameter" table="record_extension" parentfield="">

Set parent's to none which means , duplicate names and do not build tree or path for object.

<type name="NewMidgardSnippet" table="snippet" parent="NewMidgardSnippetdir">

Parent is not set at all so by default we set "up" field ( or property ) as parent.

Simple and clear. ( I think so :)

Class members

Posted on 2005-04-28 12:54:14 UTC.

I am sure that every Midgard developer asked himself about this "little" feature. Why all PHP objects which extend Midgard objects have no properties by default?
I was more than happy when I created PHP classess from MgdSchema classess with default members. But I was not happy when I noticed that after first request PHP produces only segfaults.

And here "dancing with per***" begins.

You can register PHP class while module is loaded and make this class persistant for every request. You do not have register it again when RINIT module function is called.
Fine. The real weird thing is that classess registered when module was loaded are persistent and not freed when requests end, but class members are not persistant and freed when every request ends. So after first request you have default_properties hash table empty and null to be freed. With every anoter request you have segfaults and segfaults and almost everything from PHP internals set as object's properties.

At last I found solution ( or maybe only workaround ). When RSHUTDOWN module function is called we do this little trick:

static void _unregister_midgard_php_class_members(gpointer key,
 gpointer value, gpointer user_data){

 zend_class_entry *mclass;
 gchar *class_name = (gchar *) key;

 class_name = g_ascii_strdown(class_name, strlen(class_name));

  if (zend_hash_find(CG(class_table), class_name, 
	strlen(class_name)+1, (void **) &mclass)==SUCCESS) {
    *mclass->refcount = 2;
    /* Keep refcount 2, destroy_zend_class function 
	decrease refcount before calling zend_hash_destroy. */    

    zend_hash_destroy(&mclass->default_properties);
  }
}

mclass->refcount is increased , so Zend won't be destroying this hash table, and thus we can detroy it and keep module working nice and correctly.

Zapisz to tak jak lubisz

Posted on 2005-04-30 15:42:19 UTC.

Zastanawiałem się przez chwilę jak mogę napisać ten krótki tekst.
Dlaczego po Polsku? Wszystko dzięki magicznej funkcji mgd_set_lang().

Funkcja mgd_set_lang użyta z wersją CVS dla Midgard Framework pozwala na tworzenie dowolnej ilości wielojęzykowych  obiektów i klass opartych na magicznej ( wiem , nie jestem skromy :) funkcjonalności "technologii" która na co dzień nazywana jest MgdSchema. A to oznacza , że można utworzyc 300 i więcej klas i tyle samo obiektów,  które swą treść ( jeśli chcemy tworzyć publikacje oparte na tych obiektach ) mogą prezentować w stu językach w zupełnej separacji od logiki programu
i niezależnie od metadanych obiektu.  Konkluzja jest  prosta : dziecinnie proste :)

Briefly in English:
Any MgdSchema object may be multilanged with schema definition:

<property "content" multilang="yes" table="some_table">

It doesn't matter which property. It's up to you. MgdSchema will take care about updates and creations.

And of course with function mgd_set_lang() :).