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

Joshua D. Drake wrote:

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).

Actually there were about 200 entries.  I suggest you look at the whole list and not the top 50 list :p

 

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\"";

This is the form object which is for backend admin form generation.  It generally has one purpose which is to make two column forms via objects.  While I'm not the author of this set of objects, I'd be happy to implement suggestions.  If you had to look that hard to find something like this, I'm pretty happy, since no one has given the project a critical review.

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

Absolutely.

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

I looked at some of the more popular i18n implementations, and decided that I could more easily implement an xml or pgsql table based implementation.  It's super flexible, and allows for pretty elaborate conditionals.  Perhaps you didn't look at the way the XML structure is set for the i18n tags?  Here's the one for the one you pointed out:

39	  <key>Visitors</key>
40	   <value>
41	    <language>English</language>
42	    <condition>$1 == 1</condition>
43	    <translation>There is currently 1 site visitor.</translation>
44	   </value>
45	   <value>
46	    <language>English</language>
47	    <condition>$1 != 1</condition>
48	    <translation>There are currently {@visitors} visitors.</translation>
49	   </value>
50	  </variable>

The great thing about the system is the fact it's very modular.  If this i18n system is sub-par, it would be very easy to implement the gnu system, for someone that wanted to deal with their files and create an interface for them.  I originally did look at gettext but came to the conclusion it wasn't designed for a living set of translations but rather for a programmer and design team to do all the translations up front, which is ultimately why I did things the way I did them.

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.

I designed the abstraction layer with PgSQL in mind, and with the idea that someone might want to come in and add support for something else.  The way the abstraction layer works doesn't affect performance at all, and allows for some unique methods of querying data in blocks.  It's very easy to code for, and allows for completely different query structures for different backends, while not having to jumble data around.  There was a lot of thought of that went into how the abstraction layer would work, and while it is quite different than the way PHP normally handles queries, there is a reason for the two step approach, that I feel justified in creating.

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?

I've been making a concious effort to go back through and update 6 month old code to reflect how we're doing things now, and to enforce some standards on contributed code.  If you'd like to help clean things up or make some constructive criticism, I'd love to hear it.

Gavin