Re: [pgsql-www] PostgreSQL.org Design Proposal - Mailing list pgsql-advocacy

From Joshua D. Drake
Subject Re: [pgsql-www] PostgreSQL.org Design Proposal
Date
Msg-id 41876C81.2040007@commandprompt.com
Whole thread Raw
In response to Re: [pgsql-www] PostgreSQL.org Design Proposal  (Alexey Borzov <borz_off@cs.msu.su>)
Responses Re: [pgsql-www] PostgreSQL.org Design Proposal  ("Gavin M. Roy" <gmr@ehpg.net>)
Re: [pgsql-www] PostgreSQL.org Design Proposal  (Alexey Borzov <borz_off@cs.msu.su>)
List pgsql-advocacy
>
>
>>
>>
>> BTW I don't know if anyone noticed but FrameWerk was a prizewinner with
>> the PHP 5 coding contest.. so go Gavin.
>
>
> Yes, it has achieved a whopping 18th place (out of 50).


I am sorry, did you have an entry in the contest that placed?

>
> I've downloaded Framewerk and gave it a quick review. There are some
> Bad Code Smells that will make it hard to manage in the long run:
>
> 1) HTML generated as PHP strings;
>   It is not necessary to use some "template engine" but code
> generating data structures for output should be separate from code
> outputting this data which can be e.g. HTML file with minimal PHP.
> Changing the design done in the following way is *extremely* difficult:
>
>       $ret .= "\n<form name='edit' action='$this->action'
> method='$this->method'>\n";
>       $ret .= "<blockquote><table class='form' width='98%'
> border='0'>\n";
>       foreach($this->fields as $field)
>       {
>         $ret .= "  <tr valign='top'>\n";
>         $ret .= "    <td class=\"formitem\"";


Yea I would have to agree with this one, but I am sure that Gavin
appreciates the feedback.


>
> 2) Usage of homegrown i18n solution rather than some established ones
>   Isn't it obvious from the first glance what this string does?
>   {!i18n:visitors:{@visitors}}

Well there may actually be a good reason for this.

>
> 3) Abstraction of DB API rather than usage of proper data access layer
>   This is BTW the reason for poor PostgreSQL support in most PHP
> applications: their authors use such "abstraction layers", but design
> schema for MySQL and then just do minimal "translation" of queries
> they do. Upper levels should know nothing about SQL and just call
> lower level to fetch some data.

Well I am sure Gavin isn't suffering from the translation of queries
issue but there is a lot of good reasons to abstract the DB API.

>
> 4) Lack of consistent coding standards.
>   One can say many bad things about PEAR, but its code is at least
> readable and one always knows where to find things.

The product isn't even 1.0 yet and very few people are using it. If you
are unhappy with it, why not donate some resources
and help make it a better product?

Sincerely,

Joshua D. Drake

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
>      joining column's datatypes do not match



--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment

pgsql-advocacy by date:

Previous
From: Robert Bernier
Date:
Subject: creating an informix job bank
Next
From: Robert Treat
Date:
Subject: Re: creating an informix job bank