On Fri, Apr 24, 2009 at 10:06 PM,
<mva@xxxxxxxxxxxx> wrote:
René Dudfield <renesd@xxxxxxxxx>:
hi,
very awesome of you to go ahead with this...
I read through your website... and it's got some good ideas...
It'll be cool if we can make pygame one of the best sites around in the
python scene again... the current one is from around 2005... and has been
really good so far.
Well, the colours started to hit some nerves for me, so it might be better
to go with some pastel colour palette for the new one :-).
yeah, perhaps. We should probably have the graphical design as a separate step. So we can choose the best design made available.
Rewriting the current functionality in python first could be a good way to
go. Once the current site is replicated, then move on to other stuff.
All the old stuff needs to be written at some point... because we need to
keep all the old urls around (including feeds). Also it's easier for people
Is there a way to have some easy to manage URL rewriting/forwarding in
Django? That way we could let existing URLS resolve to the new stuff (e.g.
place the currently static html sites into the DB and link to them).
Almost all web toolkits have decent url schemes, and rewriters. It can
also be done at the apache, and wsgi levels too. The current website has a
pretty good system... where it uses a database of rewrite rules
editable through the web in the management system... but we can easily use mod_rewrite or whatever we need.
I don't think we have agreed on Django specifically yet. At least pymike, and I have suggested using cherrypy. Also I know Nicholas has made the last few websites he worked on with cherrypy.
So we should decide this based on what the contributors to the website feel is best, and also the people who will maintain it.
to work towards something that exists, rather than working towards a new
design.
A new design is necessary in my opinion. Colours, overall style, etc.
The functionality though needs to stay the same (with improvements all over
the place).
Sure, but that can happen after the current one is updated. It's much easier to make design as a separate stage.
So when reimplementing it we have the current website as a reference. With a new graphical design coming afterwards(or designed separately in parallel).
First steps are to agree on a way forward... but if we go with remaking the
existing site... we could follow this path:
- prepare html/php/sql from old site.
- get old site running outside of the main pygame.org so people can test it
easily.
The current one is already around and was widely tested. Or do I miss
something here?
Yeah, that can be used for lots of things... but not all. So as to test things without messing up the main website... eg adding projects, wiki pages, news etc. Maybe we don't really need to do this... and can just look at the code mostly.
- decide on which tools we are to use. The main ones from people interested
seem to be a django, or a cherrypy based site.
- start writing the models for the various tables, and data types in
existing site (eg, project, user, wiki page, etc).
- collect a list of existing urls.
- collect a list of existing functionality.
- collect a list of html/php pages to convert to templates.
- start working on list of functionality, and templates until it is
complete.
Sounds good to me. Though I'd go with the existing functionality first. The
existing URLs and such are things to be considered for a final migration.
Thus I would move this to the end:
- work out migration plan:
- migrate projects and static content
- add functionality for eixsting URL handling
- replace existing website on
pygame.org, and make sure it works ok.
- END. then can work on adding new stuff.
the existing structure.
Working out the migration can happen in parallel to the test phase. Letting
people test is nothing, which should keep you on a 24/7 work load, so while
anyone plays around with it, you can work on the necessary conversion system.
Yeah good point.
We will need to make sure the existing data can be put into the new website at some point.
It can be easy to take the existing database and just use that. This is quite easy to do with things like sqlalchemy and the like.
So to decide which way we go, we should study the database structure to see if it is ok.
Migrating the data is probably easiest if we use the existing database directly.
The wiki code is mostly html, so isn't that hard to convert.
Sounds reasonable - google already has the whole functionality for the project,
Julian currently hosts privately. It might be good to use google's wiki there
and a seperate website SVN branch. Especially since the final system could be
adopted by other community-driven projects.