Zend = exit

I did a few size checks:

MageDB with Zend
MageDB without Zend
Zend

The results are yet again surprising to me.
MageDB with Zend  is a freaking 20.0 MB
MageDB without Zend just is: 681.7 KB (note: this is WITH Dwoo! which takes up 495.4 KB of that 681.7 KB and that means MageDB itself (the core) is: 186.3 KB)
Zend alone is: 19.4 MB

Add to this the performance (in requests per second) loss i would have had if Zend was included and the size of the complete MageDB package.
That gives me enough reasons o just drop Zend.

So how am i going to replace Zend’s modules that i WAS using?
I where just 3 modules (that sucked up over 50 includes)..

• Db [ - Done - ]
  Going to skip this all together, make a few functions to have nicely formed database arrays but that’s it.
• Translate [ - Done - ]
  Going to recreate it based on INI files or just a big PHP array. This is probably the hardest module to recreate out of the ones that i used
• Registry [ - Done - ]
  Going to recreate it
• Autoload [ Not going to do before 1.0.0 ]
  For now i won’t do anything with it. Dwoo is using it and that will stay but i won (yet) play with outoload for version 1.0.0 of MageDB

So now your all up to data again with the progress on MageDB. And i have some more work to do.

Cya,
Mark

Db update:
I’m not sure yet but i think i’m going to use the SplFixedArray for the Db. Banchmarks on the internet show that it’s a little faster then a normal array but twice as memory efficient. This does however make MageDB a PHP 5.3 or higher script! Stay tuned for more information about this Db part later this week as soon as i’ve done some tests with it.

Updates regarding “Done ” components + a bit more
For the Db component, i extended the MySQLi class (internal php class) and named it MageMySQLi. In there i implemented the fetchAssoc and fetchAll methods that you can also find in Zend_Db. Other then that nothing Db related (like query logs) is implemented. For now MageDB works again without any Zend components but with Zend LIKE components.

For the Translate component. I’m actually surprised of myself that i made that component in just roughly one hour. I made it static which means that “MageTranslate” (name of the static class) can be used anywhere throughout the code without any issues to make it global because static classes are per definition global. One thing i added that wasn’t even in the Zend_Translate module is a fallback language. For example. The default fully implemented language is going to be english for MageDB but if you add another language and use that language but one translation line is missing then it will use the fallback language which is set (by default but you can change that) to english.

Now for the registry component. That’s actually a lot like the Translate component. both are static thus global classes. The purpose of the MageRegistry is to make local variables accessible globally by putting them in a static class. You can see this as one big container where you put your stuff in. Your stuff alone without the container is hard to transport. When it’s in the container another route can be choosen and in this case it’s a open route to everywhere.

So that was one day of kicking Zend out of MageDB and replacing Zend’s components by self made small ones. This still leaves a few other components to be made:

• ACL component (for later MageDB version)
• Feed module for rss and atom feeds
• Log module for logging stuff in a database table
• Cache module for caching compiled templates
• Mail module for sending mails
• Compression module for compressing database backups
• And in time probably my own template engine

Btw. MageDB is right now faster then paFileDB  with rougly 200 requests per second more for MageDB resulting in a total of 1400 requests per second! That is FAST!! compared to a lot of other scripts.

that was it for the edit,
Mark