Thread: Re: [pgsql-www] PostgreSQL.org Design Proposal
> -----Original Message----- > From: pgsql-www-owner@postgresql.org > [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Mitch Pirtle > Sent: 28 October 2004 18:26 > To: PostgreSQL www; PostgreSQL advocacy > Subject: Re: [pgsql-advocacy] [pgsql-www] PostgreSQL.org > Design Proposal > > Dave, > > II am clearly offering to help (and not just complain), and > wanting to understand if my efforts would actually be used if > I did. I'm also busy working on other FOSS projects, with > significant time involved. > So if I spend the additional time away from my wife and kids > then I want to know it was worth it - that's not too much to > ask, is it? It will be, but you'll need to fit in with what we are doing, not the other way aound. If you really feel you need to be doing something else thoough, there are other projects that can be looked at - for example, a new techdocs site; however, it would need a thorough investigation and justification of any subequently proposed solution. Mirroring is not an issue for techdocs, however, il8n should probably be considered. > My objection to a do-it-yourself approach is that anything > beyond PEAR and PHP is proprietary. That means that you > wrote it; and as such then you have to support it, and you > have to document it, and you have to improve it, and you have > to upgrade it to keep compatibility with changes to > HTML_QuickForm and DB and so on... With a CMS, you'd > typically be using a finished system that had been developed > by dozens of people, with years of experience, with a > lifespan that supports itself (free upgrades). Such a waste, IMHO. > > I agree that mirroring is a huge problem, and anything less > than the heavyweight systems (Zope/Plone, for example) will > have major issues. > Mirroring a dynamic site in general is a major issue, and > switching to a homegrown one just adds to the complexity and > effort, no? Which is why we investigated CMSs in depths before we started, and found that even advanced ones such as Bricolage couldn't meet our requirements :-(. > And I wasn't being rude IMHO, I've already picked on Dave for > his browsing preferences. He says he has a huge monitor, but > surfs the web like he is on a Mac Plus. Having a design that > supports 800x600 to support the handicapped and comply with > accessibility laws is great in my book. I just think Dave is > being a weirdo for using such a little browser window ;-) > Sorry that wasn't so apparent in my previous email. Maybe (there are certainly people that know me better and probably wouldn't disagree!), but there are two reasons for that: 1) I have users at work with visual problems who run large monitors at low resolutions. In the UK it is a legal requirement for any organisation to provide websites and other services in an accessible form for such people. 2) Often when I'm browsing, I have many other windows open because I'm programming. I don't want to switch between them all the time, I want them side by side so I can read reference material, and code. Apps like Visual Studion take a lot of real-estate, and I'd rather not compromise that by being forced to use 3/4s of my screen just to refer to the libpq docs. Regards, Dave
В Птн, 29.10.2004, в 09:52, Dave Page пишет: > Which is why we investigated CMSs in depths before we started, and found > that even advanced ones such as Bricolage couldn't meet our requirements > :-(. In view of the fact that the current site does (probably) not only not meet your requirements, but also doesn't meet the perceived needs of the web site's users, wouldn't it be wise to adjust your requirements so that bricolage or plone or whatever fit, in order to get something going? Thanks -- Markus Bertheau <twanger@bluetwanger.de>
Markus Bertheau wrote: > > wouldn't it be wise to adjust your requirements so > that bricolage or plone or whatever fit, This is probably the ultimately helpful hint for the novices working on the new site, we all know that the postgres community consists mainly of raw beginners... Regards, Andreas
Dave, > Which is why we investigated CMSs in depths before we started, and found > that even advanced ones such as Bricolage couldn't meet our requirements > > :-(. No offense, but nobody "investigated existing CMSes in depth", or if they did, it was not discussed on WWW. What happend in my recollection was that the people who were in favor of CMSes (like me) were not willing/able to do the work to set them up, and the people who liked a more nuts-and-bolts system were willing to do the work, so that's what we went with. The people who do the work get to make the decisions on how it's to be done. Bricolage, for example, runs the WHO web site, the Register, Radio Free Asia, and and several other major, multi-lingual sites. It is also designed for mirroring, working on the idea of "burning" stuff to HTML files instead of dynamically served content. It's quite capable of doing PostgreSQL.org. The problem is that it requires Perl Mason expertise to set up and design pages, and our WWW team is primarily HTML and PHP coders. 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. -- Josh Berkus Aglio Database Solutions San Francisco
>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. Sincerely, Joshua D. Drake -- 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
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. Thanks :D I wish it was then where it is now, I probably would have placed higher :x We should be nearing a 1.0 release mid-November, though what's there now is usable, just sans installer, and is missing a few needed features for non-tech savvy users. Gavin
Hi, Josh Berkus wrote: >>Which is why we investigated CMSs in depths before we started, and found >>that even advanced ones such as Bricolage couldn't meet our requirements >> >>:-(. > > No offense, but nobody "investigated existing CMSes in depth", or if they did, > it was not discussed on WWW. What happend in my recollection was that the > people who were in favor of CMSes (like me) were not willing/able to do the > work to set them up, and the people who liked a more nuts-and-bolts system > were willing to do the work, so that's what we went with. The people who do > the work get to make the decisions on how it's to be done. > > Bricolage, for example, runs the WHO web site, the Register, Radio Free Asia, > and and several other major, multi-lingual sites. It is also designed for > mirroring, working on the idea of "burning" stuff to HTML files instead of > dynamically served content. It's quite capable of doing PostgreSQL.org. > The problem is that it requires Perl Mason expertise to set up and design > pages, and our WWW team is primarily HTML and PHP coders. Yes, exactly, so now we must choose between an ugly (I openly admit this) system written in ugly PHP that *runs* the current development version of postgresql.org [1] (that BTW has some open TODO items [2]) and a wonderful state-of-the-art CMS written in magnificient Perl that could *potentially* run a splendid new postgresql.org, if only someone actually wanted to do some work instead of praising the virtues of that particular CMS. Isn't the choice obvious? ;) > 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. [1] http://wwwdevel.postgresql.org/ [2] http://wwwdevel.postgresql.org/todo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Bricolage... > The problem is that it requires Perl Mason expertise to > set up and design pages, and our WWW team is primarily > HTML and PHP coders. Well, in all fairness, I'm a Perl wizard who would actually contribute a lot more to the web code were it not written in PHP. :) There may be others. Also, the author of Bricolage is fairly active on some of our lists, and I'm sure would be very willing to help out. Bricolage would actually be a really good choice for our website (if not now, then later) as it is one of the best products out there (in any category) that showcases PostgreSQL. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200410311939 -----BEGIN PGP SIGNATURE----- iD8DBQFBhYZBvJuQZxSWSsgRAmEcAKDiSN/0ovuL6kaTgt8vKI6DtAi4kQCeKul4 m7zv0YOrCBHNxkfJMWq29AY= =GLFF -----END PGP SIGNATURE-----
On Sunday 31 October 2004 19:40, Greg Sabino Mullane wrote:
> > Bricolage...
> > The problem is that it requires Perl Mason expertise to
> > set up and design pages, and our WWW team is primarily
> > HTML and PHP coders.
>
> Also, the author of Bricolage is fairly active on some of
> our lists, and I'm sure would be very willing to help out.
> Bricolage would actually be a really good choice for our
> website (if not now, then later) as it is one of the best
> products out there (in any category) that showcases PostgreSQL.
I know no one believes that the web team ever looked at any CMS packages, but
just a couple of the problems that bric had were supporting the interactive
docs, duplicating content out of CVS, and the ability to do translations of
content. On the latter David even said that it was something that could not
be supported *at the time*, and we certainly were in no position to hire him
to do the work needed to get it supported. AFAIK he did have plans to fix
the latter for another client, but I'm not sure if it is done, nor feeling
overly optimistic that there is enough developer support to help setup or
debug a new installation for the postgresql website (since I'm sure it would
require more than just David being willing to "help out")
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
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.
Guys, Where should the following notice be posted? The office is making the move to creating a list of PostgreSQL people to hire as contractors who have Informix experience. Actually, my guess is that anybody who has a few years experience should look into making an application and getting their name on the list. Here's the actual email that they sent me that will be posted: ---- SRA-America is having an open call for resumes/CVs for upcoming projects for 2004 and 2005. If you have experience in the migration of the large commercial databases to PostgreSQL, or if you have worked extensively with PostgreSQL and another database we want to hear from you. Please email your resume/CV to consultants@sraapowergres.com ---- thanks
>
>
>>
>>
>> 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
On Tue, 2004-11-02 at 05:41, Robert Bernier wrote:
> Guys,
>
> Where should the following notice be posted?
>
> The office is making the move to creating a list of PostgreSQL people to hire
> as contractors who have Informix experience. Actually, my guess is that
> anybody who has a few years experience should look into making an application
> and getting their name on the list.
>
> Here's the actual email that they sent me that will be posted:
>
> ----
> SRA-America is having an open call for resumes/CVs for upcoming
> projects for 2004 and 2005.
>
> If you have experience in the migration of the large
> commercial databases to PostgreSQL, or if you have worked extensively
> with PostgreSQL and another database we want to hear from you.
>
> Please email your resume/CV to consultants@sraapowergres.com
> ----
>
Job posting should be sent to pgsql-jobs@postgresql.org.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Joshua D. Drake wrote:
Gavin
Actually there were about 200 entries. I suggest you look at the whole list and not the top 50 list :p
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).
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.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.Absolutely.
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: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}}
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.
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.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'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.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?
Gavin
Hi, Joshua D. Drake wrote: > I am sorry, did you have an entry in the contest that placed? No, but I maintain several well-downloaded OS PHP projects. > Well there may actually be a good reason for this. > > 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. > > 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? Why are you behaving so protectively? I am already contributing to the project, by reviewing it and giving pointers to possible future fixes and enhancements. Besides, if you want a project to ever reach 1.0 and have a lot of users, you have to consider architectural decisions in advance.
Hi,
Gavin M. Roy wrote:
>>> 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.
You mean people using your framework will be unable to use this form-generation
class in the frontend of the website? Will they need to code all forms by hand?
'Cause if you expect them to use it in frontend, they'll definitely want to
change the design.
The suggestion is simple: abstract form generation from actual output. Generate
an array of form elements' HTML and later iterate over it or even use something
like Visitor pattern as QuickForm [1] does.
> 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.
Consider this: maybe I just know where to look and what to look for? ;)
>>> 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:
It is impossible to say what string will be output by just looking at this
placeholder in the template, while it is obvious when using gettext(). As for
conditionals, gettext allows them, IIRC.
>>> 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.
You didn't understand my point. I mean the following: your upper layer still
contains SQL queries, here is a typical example from TCMSViewer class:
$this->Database->AddQuery("key_lookup", "SELECT a.*, b.*,
to_char(a.created, '" . $this->parent->Configuration->datetime_format . "') AS
update FROM cms_entries AS a, cms_keys AS b WHERE b.cmskey = a.cmskey AND
a.cmskey = '$1' AND a.approved = 't' AND a.active = 't' AND a.language =
'$language';");
As you see, the call only abstracts DB API, it does not abstract actual query
which contains PostgreSQL-specific to_char() formating function.
If you did the Right Thing, there would be no query here but just a call to a
hypothetical loadCmsKey() method of hypothetical DAO.
> 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.
Create your own coding standards or adopt existing ones. Make all existing code
follow them --- there are automatic code beautifying tools available, you know.
Do not accept contributions not following the standards.
[1] http://pear.php.net/package/HTML_QuickForm
>> 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? > > > Why are you behaving so protectively? I felt, possibly incorrectly that you were attacking what I consider a decent project. This could very well be what Josh Berkus was speaking about in terms of language barriers etc... If that is the case I apologize. Sincerely, Joshua D. Drake > > I am already contributing to the project, by reviewing it and giving > pointers to possible future fixes and enhancements. > > Besides, if you want a project to ever reach 1.0 and have a lot of > users, you have to consider architectural decisions in advance. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL