Piotras' blog: Archive

Collecting good conventions

Posted on 2006-07-07 12:10:31 UTC.

MidgardCollector implementation is in progress. Briefly I can explain what collector is ( or what should it be ) for those who do not know it exactly.

MidgardObject methods gets all object's record and its data from database unconditionally. It means that all you can do is get particular record identified by some id or guid.

MidgardQueryBuilder is able to select objects' records from database and use or developer is able to limit selected records using constraints and thus can fully "interact" with 'WHERE' part of the SQL query.

MidgardCollector is something much more flexible. User or developer is able to limit 'WHERE' part of SQL query but additionally is able to limit 'SELECT' part of the SQL query. What is more important , selected data in collection can be overwritten via collector's API so the whole collection can be set "manually" by human or by SQL query.

I knew that MidgardCollector implementation is going to be hard , but I didn't thought that is going to be the most difficult part of midgard-core since new MidgardSchema technology has been announced.

1. MidgardCollector extends MidgardQueryBuilder. Well... easy to say if you consider that first QB implementation is not GObject's OO and the whole QB internals is shared in 5~6 files without public members, so trying to keep encapsulation of "class" internals and sharing public data means: refactor me.

2. Make yourself confused if you want to follow GObject's examples from manual and code conventions used for GValues. There is important difference between :

GValue value = {0, }; /* convention */

and

GValue *value = g_new0(GValue, 1); 

The first one "initialization" end up with voodoo segfaults if you try to manipulate "the pointers" here and there and additionally provide them for PHP language bindings.

3. Make midgard_collector class derived one for PHP language. Especially when C structure of midgard-core is implemented as MidgardQueryBuilder PHP class breaking convention which says "do not use CamelCaps" for midgard classes. Well... I added midgard_query_builder class for midgard-php and thus I can easily follow midgard-core there and keep consistent logic for class names.

4. Zend conventions "rules". I wonder how many zend developers made me a target for a shotgun if I have never said anything good about zend.

a. Register internal class for PHP using Zend.( Please guys! Never mix up php and zend names! )
API provided by Zend developers requires hardcoded! class name passed as argument because the API in this point uses sizeof instead of strlen. So simply forget about dynamic class names pointers used through this part of API.

b. I am awfull right now , I know it:
There is no "Zend manual" part on php website. Instead you can follow excellent link "Hacking the core of PHP". "Thank you!"

c. PHP5 ( language based on Zend2 engine ) comes back to old convention to use CamelCaps for function and methods name. I know , one can use CamelCaps with PHP4 , but this is nothing but php developers ( or maybe only pear ones ) convention , because Zend doesn't use upper cases in names , forcing every single string to me lowercased. Try to be so smart then and use black magic and get class name or method name if what you can get is MidgardQueryBuilder or MiDgArDqueryBuilDER. One may use g_ascii_strdown all the time , but it's not the point to remember about this. Especially when midgard community already has been affected by such API change using PHP 4.x branch.

And hey! Last but not least! While beeing coach potatoe , try to be a monkey for a few minutes when you can follow monkey guys trip every evening :)

Aha! I could forgot. Seems that deathmonkey race time has some additionall 15 hours included.

midgard_language

Posted on 2006-07-24 16:54:06 UTC.

While discussion about midgard multilingual feature is in progress I added new midgard_language core's class.

Language class is defined as MgdSchema class so it's fully usable with Midgard Query Builder and sitegroup 0 admin can update languages or create new ones.

midgard_language has predefined 51 languages following ISO 639-1 language codes and names. If you want to update some language use midgard_language.sql file located in midgard/src/data/midgard CVS subdirectory.

Every language object has defined id property to use almost deprecated now mgd_set_lang function which requires id as argument. As soon as we release 1.8 stable , app's languages will be settable via $_MIDGARD object ( not array ) with its corresponding guid. I think guid is best choice as we can switch to ISO 639-2 or 3 in a future.

For those who would like to test midgard_language:

$qb = new midgardquerybuilder("midgard_language");
$qb->add_constraint("code", "=", "en");

$ret = $qb->execute();

if($ret) 

    mgd_set_lang($ret[0]->id); 

$article = new midgard_article($guid); 
$article->content = "Some only english text";
$article->update();

In other news: midgard_collector is already implemented in midgard-core and PHP bindings for midgard-php are ready as well.

Multilingual midgard_topic

Posted on 2006-07-24 20:44:05 UTC.

Just wrote about midgard_language. So , while beeing in multilingual mood I updated midgard_topic so this class uses mulitlang Midgard feature now.

Added new multilingual title property.
Moved extra and description properties to lang table.

Well... I just reminded myself how many work had to be done with Midgard 1.4 to provide new feature , class definition and SQL queries needed for them.

With almost new Midgard2, such changes are... trivial.

Thoughts are in the air :)

Posted on 2006-07-29 14:04:50 UTC.

Tigert just mentioned about Midgard for Gnome desktop.
Bergie mentioned about GnomeGard project many many many months ago.
And I , for last two weeks think almost about nothing but some Gnome desktop application which could be used as simple Midgard Object's editor.

I am tired with editing css files via web browser. I am tired with editing code via phpmole.
As plenty of code , especially style's one resides in Midgard database , I can not use any simple text editor. WebDAV support is far from being perfect and usable.

I just installed Glade with the basic simple idea:

* Browse midgard classes
* Browse Midgard objects
* Use midgard_reflection_property to define object's property edit widget.
* Connect with Midgard API ( no need to configure Apache vhost for this )

To be shameless. Midgard core API in current state , today, is ready for Gnome desktop.
Even if such aplication is going to work in a year, I am going to write it.

MOB mock-up

Posted on 2006-07-30 14:05:12 UTC.

As soon as I installed glade I created new project. Compiled with midgard library and used few widgets. In this mock-up you are able to select configuration name from the list. Connect to Midgard database and see all MgdSchema classes in GtkTreeView widget. And of course display about window :)


It's enough to install midgard-core and dev packages ( libmidgard9 and libmidgard9-dev in my case ) and use it with glade. No hacks , no workarounds. Just easy as it should be. Just yet another gtk application.