Skeleton Framework - initial thoughts
Posted: Mon Mar 17, 2008 11:19 am
I had a quick glance at the framework, and what I think it's major problem is, is an advanced form of OOP-ittis 
Seriously, I don't think it's normal to have that amount of code split into that amount of files. Following a simple action requires opening of numerous files, where numerous objects delegate roles which noone would never want to change (so, there wasn't any need of that delegation in the first place). I don't have the code now so I can't give concrete examples at the moment, but the numbers kinda speak for themselves.
I went to take a look at the sql layer, and I'm unimpressed. The fluent interface is a nice OOP gimmick, but not very suitable for the task. While I'm all for using an SQL generator instead of writing SQL code, in the end the PHP becomes LONGER than the corresponding SQL code, with little to no added benefit. I would expect a generator to ease the majority of work related to writing SQL code. The only benefit I see from this is that a PHP interface is still better than string concatenation, and that you could still write an upper layer on top of this one and work with SQL from a higher level. The separation of SQL code and DB driver is also ok, but not really called for (IMO, could be wrong. Any of the authors care to justify it?)
There is a security vulnerability in the way SQL parameters are escaped, which would allow quoteless SQL injection to be used. I'll leave it as an exercise for the reader, at least until I go home and paste the code
Seriously, I don't think it's normal to have that amount of code split into that amount of files. Following a simple action requires opening of numerous files, where numerous objects delegate roles which noone would never want to change (so, there wasn't any need of that delegation in the first place). I don't have the code now so I can't give concrete examples at the moment, but the numbers kinda speak for themselves.
I went to take a look at the sql layer, and I'm unimpressed. The fluent interface is a nice OOP gimmick, but not very suitable for the task. While I'm all for using an SQL generator instead of writing SQL code, in the end the PHP becomes LONGER than the corresponding SQL code, with little to no added benefit. I would expect a generator to ease the majority of work related to writing SQL code. The only benefit I see from this is that a PHP interface is still better than string concatenation, and that you could still write an upper layer on top of this one and work with SQL from a higher level. The separation of SQL code and DB driver is also ok, but not really called for (IMO, could be wrong. Any of the authors care to justify it?)
There is a security vulnerability in the way SQL parameters are escaped, which would allow quoteless SQL injection to be used. I'll leave it as an exercise for the reader, at least until I go home and paste the code