MgdSchema , once please.
Posted on 2004-12-21 18:40:29 EET.
I am starting asking myself "what this MgdSchema is?!".
I proposed mRFC 0012: MgdSchema and now I wonder if we could talk about MgdSchema as only xml file where you can define all future Midgard objects.
Well, if you really need to have MgdSchema support you can just think about "how that should work" and start writing the code.
OK, what we should start from? Parsing xml.
Well, do I really need to start parsing xml if I am really not sure what data should be included in xml?
OK, let's make some draft code.
Well, do I really want to write draft code if I am not sure what I should do with data included in xml?
OK, too many questions. Let's start to write GObjects code which may be easily used with xml parsing utilities.
What was that "to heaven" in Led Zeppelin's song? ;)
GObjects and GTypes are pretty fine. Especially when you can read some docs and comments like this from http://www.le-hacker.org/.
"People often get confused when trying to construct their GObjects because of the sheer number of different ways to hook into the objects's construction process: it is difficult to figure which is the correct, recommended way."
Ah, there is no correct way. Good :)
Anyway , if you start to write some GObjects management code ,you can easy find your best way to start working with GType system.
At least I found myself and suddenly I discovered that I can not easily create object properties as these should be hardcoded at some point ( yeah, it is not PHP where you can add object property on the fly). So I found "my way" is bad way. Which way then?
Luck! Alexander wrote some code which DO automagic properties creation. Right! All in all what you need is guint , integer value which tells you about property. You even do not have to know object's property name. Great. What next? Class inheritance.
Piece of cake. With demo code which was written by Alexander for developers meeting at Poznan, you may find that all we need is GHashTable to store all Midgard types like MgdArticle or MgdPerson. Do we? Piece of cake? If you want to provide GHashTable as Midgard types storage the best way is to define one global array, but we need to define MgdSchema per Vhost or per application. So all code which register Midgard types should highly GHashTable dependant. No, no this is not piece of cake.
At this point I should start writing xml parsing and GHashTable utilities to get correct arrays to store GObjects. But, "do I really want to write draft code if I am not sure what I should do with data included in xml?". I think I saw my tail for a while ;)
Good point is to start working with GTypeInfo , but unfortunatelly there is no way ( it seems like ) to get this type knowing only class name. My god, I like it... A good solution seems to be slow down "a bit" MgdSchema creation and count all parent object properties before extending. Not the best solution if you think about speed , but this is could be done once and be independant from GHashTable arrays. We will see...
I proposed mRFC 0012: MgdSchema and now I wonder if we could talk about MgdSchema as only xml file where you can define all future Midgard objects.
Well, if you really need to have MgdSchema support you can just think about "how that should work" and start writing the code.
OK, what we should start from? Parsing xml.
Well, do I really need to start parsing xml if I am really not sure what data should be included in xml?
OK, let's make some draft code.
Well, do I really want to write draft code if I am not sure what I should do with data included in xml?
OK, too many questions. Let's start to write GObjects code which may be easily used with xml parsing utilities.
What was that "to heaven" in Led Zeppelin's song? ;)
GObjects and GTypes are pretty fine. Especially when you can read some docs and comments like this from http://www.le-hacker.org/.
"People often get confused when trying to construct their GObjects because of the sheer number of different ways to hook into the objects's construction process: it is difficult to figure which is the correct, recommended way."
Ah, there is no correct way. Good :)
Anyway , if you start to write some GObjects management code ,you can easy find your best way to start working with GType system.
At least I found myself and suddenly I discovered that I can not easily create object properties as these should be hardcoded at some point ( yeah, it is not PHP where you can add object property on the fly). So I found "my way" is bad way. Which way then?
Luck! Alexander wrote some code which DO automagic properties creation. Right! All in all what you need is guint , integer value which tells you about property. You even do not have to know object's property name. Great. What next? Class inheritance.
Piece of cake. With demo code which was written by Alexander for developers meeting at Poznan, you may find that all we need is GHashTable to store all Midgard types like MgdArticle or MgdPerson. Do we? Piece of cake? If you want to provide GHashTable as Midgard types storage the best way is to define one global array, but we need to define MgdSchema per Vhost or per application. So all code which register Midgard types should highly GHashTable dependant. No, no this is not piece of cake.
At this point I should start writing xml parsing and GHashTable utilities to get correct arrays to store GObjects. But, "do I really want to write draft code if I am not sure what I should do with data included in xml?". I think I saw my tail for a while ;)
Good point is to start working with GTypeInfo , but unfortunatelly there is no way ( it seems like ) to get this type knowing only class name. My god, I like it... A good solution seems to be slow down "a bit" MgdSchema creation and count all parent object properties before extending. Not the best solution if you think about speed , but this is could be done once and be independant from GHashTable arrays. We will see...