Category: "b2evolution"

Rasmus on templating engines

At PHP Forum, Rasmus said this about the "templating engine question coming back every year":

PHP *is* a templating engine by itself. Adding another templating engine on top of it just doesn't make sense. The only situation where it makes sense, is when you don't trust the template to contain nice behaving code.

I so much agree...

Of course, in b2evo, you can't always trust the template/skin... so we'll need to implement some kind of templating... but we're really gonna make it lightweight!

New feature: send message to author

Okay, I just put up this new feature from b2evolution/Phoenix on my blog: next to every post and every comment, you'll see a little envelope. When you click on it, you're offered to send a message to the author.

The message gets sent by email, but you never see the email address... for (quite) obvious spam defeating reasons.

I'm not sure though if that's enough. The form itself might become a (comment) spam target and I'll get twice as much comment spam as usual.

Worse, the commenters might get some of it too... Humm... :roll: I just want to run this for a few days and see how it works before I take it down... :-/

Anyway, let me know how you feel about it. Thanks.

PS: there may be some other bugs due to software upgrade. Please let me know and I'll correct asap.

The illusion of DataBase Abstraction Layers or Classes

Many people think that DB abstraction is cool. I get emails about this topic all the time. People suggesting we add a DB abstraction layer to b2evolution, or offering to do so themselves.

So why haven't we added one yet? Well, simply because DB abstraction doesn't work! :!:

DB abstraction layers will mostly hide the specific interface semantics between the application and the database. Thus you don't have to worry about the specific system call to connect to each particular DB. OK nice. So what? That's only the easiest part in porting an app from a DBMS to another... (BTW, we use a class (/evocore/db.class) in b2evolution for this too. You just have to slighlty alter this class if you want to connect to another DBMS than MySQL).

More sophisticated layers will also translate between different datatypes from one DBMS to another. But since datatypes tend to standardize among all popular DBMSes this is getting less of an issue as time passes by...

Finally, we get to the point where it hurts: the SQL syntax! There are vitually no two DBMSes that share the exact same SQL syntax, except for the most basic SELECT, INSERT, UPDATE and DELETE statements! >:-[ And it doesn't seem to be standardizing really... some still won't support even the minimalistic SQL 92 standard! >:XX

Just check it out with your 2 favorite DBMSes:

  • How do you perform a LEFT OUTER JOIN?
  • How do you concatenate columns into a single result string?
  • How do you limit results in the WHERE clause to a regular expression?
  • How do you handle the fact that when you INSERT and the primary key already exists, you want to UPDATE instead? (MySQL's REPLACE INTO syntax...)?

These are just a few common examples, but they're probably already enough to show you why you DB abstraction layer won't magically translate from you first favorite DBMS to your second... You'll have to rewrite many queries too... and sometimes you won't find equivalent functionnality (subqueries?) and you'll have to write extra application code...

Not to mention triggers and stored procedures where you wouldn't even dare to dream about some kind of compatibility.

The most advanced DB abstraction I have ever worked with was ODBC. Yes that thing actually did SQL syntax translation! But it depended on specific drivers to implement translation against a standardized syntax defined by Microsoft.

So today when I see some open source library pretending to perform DB abstraction and I can't find anything closely related to SQL syntax translation, I won't even consider it... It's useless to me. The real difficulty with handling multiple DBs is rewriting the SQL queries, triggers and stored procedures... it's not connecting to yet another fancy DBMS and SELECT 'hello'... |-|

There's more than the code...

Oh well... I think it's been too long since I last read some great wisdom like the one on Joel on Software.

I read this really insightful peace today about all the important things beyond just the actual software code.

Here's a funny quote:

Human emotions can be really, really superficial. In particular people ridiculously overvalue aesthetics and beauty when evaluating products. It's one of the reasons iPods, and, for that matter, Keanu Reeves, are so successful.

...but the whole article is definitely a must read!

Of course, this so much applies to b2evolution as well... :-/

Using PHP 4.3.8 with MySQL 4.1

Running an app under PHP 4.3.8 and trying to connect to a MySQL 4.1 database can be pretty frustrating. By default it gives you a message like this:

"Client does not support authentication protocol requested by server; consider upgrading MySQL client".

The problem is that by default PHP's MySQL module is compiled with an older MySQL client library. MySQL has a manual page about this.

I use the OLD_PASSWORD method. I connect to MySQL under root with MySQL Query Browser and I issue the following command:

set password for 'demouser' = old_password('demopass');