13/06/2005
PLog
Je vais commnencer une série d'articles sur les outils de blogging opensource. J'essaierai de les comparer en précisant leurs forces et faiblesses. pLog est un outil que j'ai récémment découvert.
Une installation simple et sans difficultés particulières. Un éditeur html intégré qui semble avoir encore quelques problèmes d"intégration. Une sauvegarde de l'état brouillon grâce à AJAX. 1ère fois que je vois ça sur un outil de blogging. Je pense que c'est quelque chose qui va se démocratiser de plus en plus sur certaines actions. On pourrait imaginer une sauvegarde automatique via AJAX ça serait encore mieux : plus besoin de cliquer sur enregister à l'état brouillon.
Une fonction intéressante est la possiblité de rajouter des champs personnalisés. Cependant il ne s'affiche pas dans le blog donc l'intérêt devient moins important. J'aurai préféré choisir un gabarit de note. Une note ressemblant à un événement, une note par défaut, ... Le reste c'est du classique avec sa gestion des plugins.
On peut remarquer néanmoins l'intégration de filtres bayesiens pour lutter contre le spam. (j'ai vu une autre implémentation de ce filtre sur http://www.xhtml.net/).
En résumé les fonctionnalités sont présentes mais l'ergonomie pourrait être améliorée.
Si on rentre dans les entrailles de pLog on voit qu'il est complétement orienté objet et qu'il utilise Smarty et adodb. Sur le wiki du projet on trouve toutes les informations pour ceux qui souhaitent développer des plugins. En regardant les ressources utilisées sur la page "New post" ; page la plus appelée de ce type d'application on s'aperçoit que le projet doit encore progresser. Quelques lignes de code insérées dans le code permettent de le voir :
register_shutdown_function("testProfiling");
function testProfiling()
{
print_r(get_declared_classes());
print_r(get_included_files());
print_r(memory_get_usage());
}
Constat : plus de 170 fichiers ouverts avec plus de 170 classes. Ce test montre simplement qu'il y a sûrement de fichiers et des classes qui sont inclus et qui ne devraient pas. C'est souvent le travers des applications qui sont trop orientées objet et qui s'inspirent trop des patterns utilisées pour java. On utilise des ressources qui son inutiles dans 80% des cas. Je pense qu'il y a un gros travail de refactoring à faire afin d'optimiser le code.
Je finirai quand même par un bon point c'est son wiki. Peu de projets ont une documentation aussi fournie et expliquent leur architecture logicielle : documentation pour les développeurs
23:20 Publié dans Outils de blogging | Lien permanent | Commentaires (5) | Tags : blog | 
del.icio.us | 
Facebook
Commentaires
Can't speak too much French, but I think it was enough to get an idea of your article... Thanks for commenting on pLog, and just to let you know that we're working hard on reducing the memory footprint and the amount of files used in every request. I do agree that the current amount is just insane.
pLog 1.1 will be released at some point after the summer and will be mostly focused on performance improvements and reduction of the memory consumption (you'll be surprised to know that we've already dropped ADOdb because it's a memory hog)
In the meantime, take a closer look at pLog if you're interested to see not just a "script" but instead, a fully-features blogging platform with a complete object-oriented API (http://www.plogworld.net/api)
Écrit par : oscar | 14/06/2005
Adodb (http://adodb.sourceforge.net/) uses more memory than a simple API but it's more powerful and faster than PEAR:DB. I haven't yet tested the extension in C but I suppose that the performance would be increased. The pLog API is good but I think it's too object-oriented. Using Smarty is a good choice. I think that the arrays are often better than classes in the templates. blogSpirit is a mixed between the both and the platform blogSpirit succeeds better in the test of my post.
Écrit par : Olivier | 14/06/2005
I never said that ADOdb is not powerful, but the problem is that it does too much considering our requirements (and the requirements of most medium PHP applications)
We ended up implementing our own DB abstraction layer (we've called it PDb -- pLog Db) which implemented only the methods that we really used from ADOdb. If you look at the MySQL driver that we implemented, it's hardly 50 lines (http://www.plogworld.net/svn/plog/plog/trunk/class/database/pdb/drivers/pdbmysqldriver.class.php) and only by changing a line in one of our classes, plog 1.1 can run without any change using PDb instead of ADOdb...
We were clearly underusing ADOdb and it wasn't worth the memory wasted on the code.
Regarding the design of pLog in general and the API, the main goal when the project started was to try to bring some organization and design concepts to PHP. There is too much "spaghetti code" out there which is giving a bad name to the PHP community. There is a lot of PHP code mixed with SQL code altogether mixed with HTML code that is basically useless outside that particular application. For example, when we implemented support for resources in pLog 0.3, I had a look at the code in Gallery 1 to see if something could be used... Nothing! It was basically a mess without proper organization, no clear separation of presentation and data access, etc. Have you recently seen the development code of Gallery2? It is completely another world! (and the gallery2 devs probably had a look at plog when implementing some of the code, some things reminded me a lot of what we've done :))
The only problem we've had so far while implementing a proper OOP application in PHP is that we were loading too much code every time when in fact, only a tiny fraction of it was being used... We've already done a lot of work in the 1.1 branch to fix this, and we'll still be working on it for the next few months. Hopefully these efforst will pay off :)
Écrit par : oscar | 14/06/2005
Salut,
tu as certainement entendu parler de DotClear !? ;-)
Bonnes études ...
++
:)
Écrit par : tbaz | 27/06/2005
Bien sûr,
Il est sur ma liste ;-)
Écrit par : Olivier | 28/06/2005
Les commentaires sont fermés.