public inbox for [email protected]
help / color / mirror / Atom feedFrom: Gavin M. Roy <[email protected]>
To: Joshua D. Drake <[email protected]>
Cc: Alexey Borzov <[email protected]>
Cc: Josh Berkus <[email protected]>
Cc: [email protected]
Subject: Re: [pgsql-www] PostgreSQL.org Design Proposal
Date: Tue, 02 Nov 2004 08:28:55 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <E7F85A1B5FF8D44C8A1AF6885BC9A0E4306E8F@ratbert.vale-housing.co.uk>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
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], [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