Page 2 of 4
Re: Distinguish Frameworks
Posted: Sat Apr 04, 2009 11:15 pm
by volomike
Sounds like what we need is a matrix here of features in frameworks, and then a Yes/No/YesBut/NoBut. The YesBut and NoBut would be one of these things with a superscript number and an explanation.
Anyone got time to kick this off some place on a wikipage?
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 3:05 am
by jaoudestudios
Does DevNet have a wiki? If not, I just setup a wiki if you guys like, it is a bit bare at the moment, need to find the time to customise it

.
You are more than welcome to use it, the link is...
http://www.wiki.jaoudestudios.com
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 9:47 am
by volomike
Thanks, that will do the trick. I added a link on the wiki and it goes to here:
http://www.wiki.jaoudestudios.com/index ... evaluation
It's ready for everyone to make a bullet list of all the framework names they know of and to hyperlink to those frameworks.
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 10:05 am
by jaoudestudios
I added the 2 frameworks I have used before.
We should have somewhere for the pros|cons of each - I am new to the wiki idea, what is the best way to do this?
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 1:10 pm
by alex.barylski
There are already lists like this:
http://www.phpframeworks.com/
http://en.wikipedia.org/wiki/List_of_we ... frameworks
The problem with these comparisons is they don't really give any idea of overall quality, IMHO -- it's a feature comparison more than anything. They simply list which kind of functionality each framework has. I could add ORM to my framework simply by using propel or doctrine.
I personally would want something a little more specific or detailed...I think we need to use quantifiable metrics which cannot be debated or disproved:
1. Bug history (which has proven to be less buggy over X months -- security too?)
2. Performance/Memory footprint
3. Dependency management (percentages?)
4. Code base consistency (conventions, etc)
5. DRY KISS
When you add up all these metrics I think you would get a much clearer idea as to which framework was of the highest quality, more stable, scalable, secure, etc, etc...
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 1:55 pm
by Bill H
Using @ is not acceptable in production code. Sorry, just that alone causes me to flag CI as a NO GO.
Would that include using it on a mysql function in order to avoid the awkward mysql error message and use a programmer-created neatly designed and site-related error message in its place?
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 2:56 pm
by alex.barylski
1+ for not using error surpression...I suppose there may be rare occassionas where it's justified and still not a design flaw -- but I cannot think of any off the top of my head.
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 3:07 pm
by Benjamin
Well you really don't have a choice as far as that goes. (Supressing mysql_query errors) Code using PDO looks a bit different though.
Code: Select all
/**
* Executes query build by createSelectSql() and returns the resultset statement.
*
* @param Criteria $criteria A Criteria.
* @param PropelPDO $con A PropelPDO connection to use.
* @return PDOStatement The resultset.
* @throws PropelException
* @see createSelectSql()
*/
public static function doSelect(Criteria $criteria, PropelPDO $con = null)
{
$dbMap = Propel::getDatabaseMap($criteria->getDbName());
$db = Propel::getDB($criteria->getDbName());
if ($con === null) {
$con = Propel::getConnection($criteria->getDbName(), Propel::CONNECTION_READ);
}
$stmt = null;
if ($criteria->isUseTransaction()) $con->beginTransaction();
try {
$params = array();
$sql = self::createSelectSql($criteria, $params);
$stmt = $con->prepare($sql);
self::populateStmtValues($stmt, $params, $dbMap, $db);
$stmt->execute();
if ($criteria->isUseTransaction()) $con->commit();
} catch (Exception $e) {
if ($stmt) $stmt = null; // close
if ($criteria->isUseTransaction()) $con->rollBack();
Propel::log($e->getMessage(), Propel::LOG_ERR);
throw new PropelException($e);
}
return $stmt;
}
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 3:22 pm
by Bill H
So, assuming that you have tested to be sure that the $Query var is a valid query string, you would not consider the use of the @ in the following to be valid?
Code: Select all
echo "<div class='cbox' style='width:605px; height:424px; border:3px inset #910000; overflow:auto; margin-top:0px'>";
$Result = @mysql_query($Query, $Link);
if ($Result == FALSE)
{ echo "<div class='black p13' style='width:600px; text-align:center; margin-top:10px'>";
echo "Database connection was interrupted</div>";
}
else
{ while ($Row = mysql_fetch_array($Result))
{
// etc
}
}
echo "</div>";
This is not the kind of thing that I do only on "rare occassionas" since I hate spending a lot of time designing an attractive screen only to have it trashed by the error messages that MySQL produces and, usually, in unformatted text.
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 3:53 pm
by alex.barylski
I'm missing something...why would mysql_query() fail in the first place on a production server?
If this fails, it should be determined during development as I can only see it failing if the SQL is faulty???
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 5:15 pm
by Benjamin
I'm either thinking of mysql_query or mysql_connect. Anyhow, I dealt with it like this:
Code: Select all
$pel = error_reporting(0);
// routes errors to a function that ignores them
set_error_handler('null_errors');
try {
if (!is_resource(($this->dbcon = mysql_connect("{$this->host}:{$this->port}", $this->user, $this->pass))))
{
throw new Exception("Failed to create MySQL database connection. #" . mysql_errno() . ' - ' . mysql_error());
}
if (!mysql_select_db($this->dbas, $this->dbcon))
{
throw new Exception("Failed to create MySQL database connection. #" . mysql_errno() . ' - ' . mysql_error());
}
restore_error_handler();
error_reporting($pel);
} catch (Exception $e) {
restore_error_handler();
error_reporting($pel);
trigger_error($e->getMessage(), E_USER_ERROR);
}
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 7:45 pm
by Bill H
All I know is that without the "@" it sometimes threw the MySQL error message. I don't know why it would do that other than that sometimes the db server is busy or not available, but it did it. (I do know that my hosting service stores the databases on a different server.) With the "@" it doesn't do it and the only error message is my nice neat one, which I like a lot better. It happens very, very seldom, but it does happen.
I certainly could write a separate error handler, and if I were doing the program in C or C++ I would do so and it would indeed be a class. On the small scripts that I'm doing these days, I don't do oop in php. I don't do abstraction for the sake of abstraction, so I probably don't qualify as a real programmer, but my scripts still run and my clients are happy with my work, so...
Sorry I butted in with my dumb question. It seemed sensible to me.
Re: Distinguish Frameworks
Posted: Sun Apr 05, 2009 10:53 pm
by alex.barylski
All I know is that without the "@" it sometimes threw the MySQL error message. I don't know why it would do that other than that sometimes the db server is busy or not available, but it did it. (I do know that my hosting service stores the databases on a different server.) With the "@" it doesn't do it and the only error message is my nice neat one, which I like a lot better. It happens very, very seldom, but it does happen.
Interesting...in that case I would see if a conditional test couldn't determine whether the DBS was down or not and display an error message that way. Alternatively I would use PDO and configure it to throw an exception, catch it and shown an error that way.
I would prefer explicit error testing over an implicit 'shhhh' error surpression technique.
I don't do abstraction for the sake of abstraction, so I probably don't qualify as a real programmer, but my scripts still run and my clients are happy with my work, so...
So long as your clients are happy and you are too, that is ultimately all that matters. Whether a good thing or bad, I actually prioritize my own happyness over my clients. If I am dissatisified with code, there is likely a good reason, and I believe eventually my clients will become dissatisfied as well (buggy, poor performance, insecure, etc).
Re: Distinguish Frameworks
Posted: Mon Apr 06, 2009 3:04 am
by Christopher
The first one is pretty useless. The second one has some interesting criteria, but is probably better at finding a framework that matches your style than anything.
PCSpectra wrote:I personally would want something a little more specific or detailed...I think we need to use quantifiable metrics which cannot be debated or disproved:
1. Bug history (which has proven to be less buggy over X months -- security too?)
2. Performance/Memory footprint
3. Dependency management (percentages?)
4. Code base consistency (conventions, etc)
5. DRY KISS
When you add up all these metrics I think you would get a much clearer idea as to which framework was of the highest quality, more stable, scalable, secure, etc, etc...
Except Performance/Memory they are all pretty subjective in that what you might consider bad numbers might indicate good qualities.
The problem with all of these metrics is they don't really get a the problem solving ability of these frameworks. How broad a spectrum of problems can they solve; how fast to implement solutions; how stable and changeable are the results.
PCSpectra wrote:1+ for not using error surpression...I suppose there may be rare occassionas where it's justified and still not a design flaw -- but I cannot think of any off the top of my head.
Database calls you should be able to handle pretty well without @. Filesystem calls however are a completely different story. I don't think anyone can build a library with them in PHP without using @.
Re: Distinguish Frameworks
Posted: Tue Apr 14, 2009 3:43 pm
by VladSun
astions wrote:Well I'm sure I'll catch flac from CI fans, but I'm sorry, 4 or 5, it's just bad code.
I'm not a "fan" of CI, but it's the only PHP framework I've used so far. I've tried several mentioned here frameworks but I didn't like them.
I do agree CI is *very* hackish, but "it works for me (c)"

. It's very simple and easy to track how it works. This allows me to modify its code easily (bug fixes, feature extension, etc.)
In fact, I don't care how it's written if it does its job. I mean, if its "API" works and reacts as expected, then I don't care
