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.
