Piotras' blog: Archive

Foreach...

Posted on 2005-01-12 11:58:35 UTC.

I just noticed that future started last week :)

What I really hate is glib hash tables iterations. While there is ( seems to be nice ) g_hash_table_foreach function , it forces anyone to write additional routine functions which are passed as parameter and sometimes must call another foreach functions. This makes life very difficult.

While we need allocate some memory for GParamSpec which should be used to register midgard classes, we must know how many properties object should have.

GParamSpec *params = g_malloc(sizeof(GParamSpec*)*(number));

Our magic "number" can not be easily get while parsing xml file as it uses _get_elements_names function which is recursive one. g_hash_table_size is  very helpfull here , as we can get later hash size , increase by 1 ( to add NULL ) and call sizeof with correct number. Yeah, this is it. But we also need at this point number  of property. That's bad.
You may create some easy gint i value which may be used in function which is passed to g_hash_table_foreach. You may , but this value will be set to 0 with every function call. I decided to change midgard MgdHash structure which has gint and GHashTable, so simple hash has also something like index.

typedef struct
{
  GHashTable *hash;
  gint n;
}
MgdHash;
 

And this seems to work fine, as indexes are automagically created while xml schema file is parsed. Some more changes seems to be required before commiting code to cvs , especially when I noticed my silly mistake. I added two header files to main src core directory. Anyway header files should be changed a lot , so fresh ones should be added in correct place.

Please, register me :)

Posted on 2005-01-12 17:57:42 UTC.

Finally.

Just called my local midgard-schema tool to check if xml file is correctly defined.

midgard-schema ./MgdObjects.xml

Debug output seems fine till now.

** (process:27960): DEBUG: Registering new 'MgdRpd' type 
(process:27960): midgard-schema-DEBUG: Source schema is empty
(process:27960): midgard-schema-DEBUG: TYPE in Schema: MidgardArticle
(process:27960): midgard-schema-DEBUG: Number of properties: 31
** (process:27960): DEBUG: Registering new 'MidgardArticle' type 

Which simply means : I defined MidgardArticle and by default now it extends MgdRpd object. There are some work left to correctly install properties and this is one of these difficult_kill_me_i_do_not_want_do_this things ;)

I also tried to register Piotrasa type, but unfortunatelly I was lazy to write all properties. Luckily mgdlib_create_schema function didn't even try to register such type.

(process:27960): midgard-schema-DEBUG: TYPE in Schema: Piotrasa
(process:27960): midgard-schema-WARNING **: Type Piotrasa has less than 1 property!

Yeah, debug output is fine , as nobody wants to know how this works ;)

MgdSchema for everyone

Posted on 2005-01-17 16:51:50 UTC.

MgdSchema was born.

g_type_init();
mgdlib_init();

MgdSchema *mschema;
gpointer *bar;
GType topic;
const gchar *name;

name = "MidgardTopic";

topic = g_type_from_name(name);

mschema = mgdlib_create_schema (MGD_SCHEMA_FILE,NULL,NULL);

bar = g_object_new (topic, NULL);

g_object_set (bar,
"title", g_strdup("My lovely title"),
"sitegroup", 12,
"name", g_strdup("name which is easy"),
NULL
);

This short code produces nice debug output:

** (process:19859): DEBUG: Midgard  class 'MidgardTopic' initialized
** (process:19859): DEBUG:  Set property title
** (process:19859): DEBUG:  Set property sitegroup
** (process:19859): DEBUG:  Set property name

And interesting thing is , this "object" was  created from such xml file:

<type name="MidgardTopic" table="topic">
  <property name="name" type="ext"/>
  <property name="title" type="text" table="topic_i"/>
  <property name="score" type="integer"/>
</type>

Interesting? Just notice that sitegroup was not defined in xml :)
So why such property was set? Because MidgardTopic is not real Midgard object.
It was midgardized :)

Good start before mgd_exorcise() ;)

<? new MidgardRocks(); ?>

Posted on 2005-01-27 17:47:55 UTC.

Yeah, Midgard really rocks.

Define Your own type in schema.

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

Open Your favourite midgard's sites editor.
Write short code:

$classname = "MidgardRocks";
if (class_exists($classname)) {
echo "Class $classname exists";
$amerigard = new MidgardRocks();
print_r($amerigard);
}?>

Point Your favourite browser to the page with the code.

Class MidgardRocks exists
MidgardRocks Object ( )

Isn't Midgard Your favourite CMF and CMS? ;)

That was "easy" part. Now there is a high time to define object's properties and methods, which should be a little painfull if you consider using "very well documented" Zend.
I was wondering today why

char class_name[] = "SomeObject";
INIT_CLASS_ENTRY(class, class_name, NULL);

works , while

char *class_name = g_strdup((gchar *)objname);
INIT_CLASS_ENTRY(class, class_name, NULL);

doesn't work.

Solution is "easy". Zend uses sizeof in macro instead of strlen which is much much better to get length of any string, right?

Dynamic registering PHP classess from Midgard schema seems to be a little better , we can remove at least 100 lines of code ( If I am not wrong ) just cause of this:

static void 
_register_midgard_php_classes(gpointer key, gpointer value, gpointer user_data){
zend_class_entry class;
class.name = g_strdup((gchar*) key);
class.name_length = strlen((gchar*) key);
class.builtin_functions = NULL;
class.handle_function_call = NULL;
class.handle_property_get = NULL;
class.handle_property_set = NULL;
zend_register_internal_class(&class TSRMLS_CC);
}

Bad thing is that we can not register objects while PHP module is loaded.

We must do it while request is initialized. I wish I could be wrong , and gladly expect any hints for this problem.

A good thing about PHP_RINIT_FUNCTION(midgard) is that we can move mgd_get_midgard code there and forget about calling this function in midgard root file. $_MIDGARD data could be initialized internally and without worry that anyone can change root file.

In other news:

Midgard Apache module (currently Apache2 at this moment) forces using utf-8 parser , so there will be no need to use MidgardParser directive. Of course I am not going to remove this directive , as someone may need to use latin-1 parser.