Re: [pygame] PyGame Website Rewrite

[Lenard Lindstrom <len-l@xxxxxxxxx>]

Are we already at the point where we can choose a framework? I am not 
experienced enough in this area to make a recommendation. I will look at 
them more closely. Django is favored at the new Pygame web site 
development Trac. Of major consideration is the ease with which the 
content of the existing site can be ported to the new site. I cannot 
even comment on that as I don't know how the existing site is 
implemented, though I guess Python is involved somewhere.

As for what I can contribute, I am taking this more as a learning 
opportunity than anything. I could probably write applications to port 
information and maybe convert wiki to pages if something doesn't already 
exist. But I will leave the framework stuff to others. I have also 
played around a bit with PovRay so could create some simple 3D effect 
controls like in the midi.py Pygame example.

Lenard


René Dudfield wrote:
> Hi,
>
> very detailed emails from Marcus and Nicholas...
>
> a few related points below.
>
>
> I'd be interested in knowing what jug, and orcun think of using 
> Django?  Also what they think of a cherrypy based stack?
>
> Also, what are the preferences of Lenard, Devon, pymike, and anyone 
> else who is interested in contributing?  Please state the level of 
> commitment you're willing to make, and also which option(s) you'd be 
> happy using.
>
>
>
>
> - The main author of cherrypy(Robert Brewer) said he'd help us with 
> any major issues we had, and so did some other cherrypy mailing list 
> people.  The cherrypy mailing list is also more active than the pygame 
> one, so I'm sure we won't have any issues with docs or help.
>
> - documentation is extensive for cherrypy(it's a 10 year old project, 
> in it's third generation).
>
> - we would have to choose a stack.  The stack Nicholas mentioned seems 
> pretty common, cherrypy + sqlalchemy + genshi + formencode/formalchemy 
> + pygame of course for imaging... and joysick control of the 
> website.   So that is the stack we would be chosing.
>
> - cherrypy code seems cleaner... as it's just python objects.
>
> class MySite(object):
>     def index(self):
>         return "hello world!"
>
>     def news(self, id=None):
>         if id is None:
>             return main_news()
>         else:
>             return specific_news(id)
>
>     index.exposed = True
>     news.exposed = True
>
> This creates these urls by default:
> /
> /index
> /news
> /news/10
> /news?id=10
>
>
> - cherrypy has less code compared to django, and is changing less.
>
> - django is usually run using apache modpython or mod_wsgi, or even 
> with cherrypy(or other wsgi server).  They don't recommend using the 
> bundled django webserver.  Whereas cherrypy is considered one of, if 
> not the best python web servers.  With cherrypy you use the same 
> webserver for development, and for production.
>
> - you can run cherrypy inside a pygame application.  Cherrypy doesn't 
> control the main loop if you don't want it to.
>
> - there are more wsgi components than there are pinax apps.  Also 
> pinax apps should theoretically be able to play with wsgi.  I'm pretty 
> sure you can use django apps as wsgi components now too.