On 31/01/2010 13:45, Magnus Hagander wrote:
On Sat, Jan 30, 2010 at 22:43, Matteo Beccati<p...@beccati.com> wrote:
On 30/01/2010 17:54, Alvaro Herrera wrote:
* While I don't personally care, some are going to insist that the site
works with Javascript disabled. I didn't try but from your description
it doesn't seem like it would. Is this easily fixable?
Date sorting works nicely even without JS, while thread sorting doesn't at
all. I've just updated the PoC so that thread sorting is not available when
JS is not available, while it still is the default otherwise. Hopefully
that's enough to keep JS haters happy.
I haven't looked at how it actually works, but the general requirement
is that it has to *work* without JS. It doesn't have to work *as
well*. That means serving up a page with zero contents, or a page that
you can't navigate, is not acceptable. Requiring more clicks to get
around the navigation and things like that, are ok.
As it currently stands, date sorting is the default and there are no
links to the thread view, which would otherwise look empty. We can
surely build a non-JS thread view as well, I'm just not sure if it's
worth the effort.
* The old monthly interface /list/yyyy-mm/msg*php is not really
necessary to keep, *except* that we need the existing URLs to redirect
to the corresponding new message page. I think we should be able to
create a database of URL redirects from the old site, using the
Message-Id URL style. So each message accessed using the old URL style
would require two redirects, but I don't think this is a problem. Do
you agree?
Sure. I was just hoping there was an even easier way (rescritct to month,
order by uid limit 1 offset X). I guess it wouldn't be hard to write a
script that populates a backward compatibility table. No need for double
redirects, it'd be just a matter of adding a JOIN or two to the query.
Once we go into production on this, we'll need to do some serious
thinking about the caching issues. And in any such scenario we should
very much avoid serving up the same content under different URLs,
since it'll blow away cache space for no reason - it's much better to
throw a redirct.
Yes, that was my point. A single redirect to the only URL for the message.
* We're using Subversion to keep the current code. Is your code
version-controlled? We'd need to import your code there, I'm afraid.
I do have a local svn repository. Given it's just a PoC that is going to be
rewritten I don't think it should live in the official repo, but if you
think id does, I'll be glad to switch.
Note that the plan is to switch pgweb to git as well. So if you just
want to push the stuff up during development so people can look at it,
register for a repository at git.postgresql.org - or just set one up
at github which is even easier.
The only reason why I used svn is that git support in netbeans is rather
poor, or at least that was my impression. I think it won't be a problem
to move to git, I probably just need some directions ;)
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
