public inbox for [email protected]  

help / color / mirror / Atom feed

From: Alexey Borzov <[email protected]>
To: Joshua D. Drake <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: [email protected]
Subject: Re: [pgsql-www] PostgreSQL.org Design Proposal
Date: Tue, 02 Nov 2004 13:07:03 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <E7F85A1B5FF8D44C8A1AF6885BC9A0E4306E8F@ratbert.vale-housing.co.uk>
	<[email protected]>
	<[email protected]>

Hi,

Joshua D. Drake wrote:
> 
>> Gavin Roy is currently working on a system, Framewerk, which may 
>> become a better fit for our community once he gets 
>> export-to-static-html working.   Actually, we could probably use it 
>> for Techdocs right now.   
>>
> We are also considering it for the plPerlNG and plPHP sites.
> We are waiting for it to stabilize (in terms of schema changes etc..)
> a bit first.
> 
> 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'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\"";

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}}

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.

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.

view thread (17+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [pgsql-www] PostgreSQL.org Design Proposal
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox